XSF Discussion - 2019-08-29

  1. ralphm

    Ge0rG: how so?

  2. Ge0rG

    ralphm: it allows the server operator to derive the user's screen time in the xmpp client

  3. ralphm

    That has almost nothing to do with the GDPR.

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

  5. ralphm

    Finally, servers don't have control over why/when clients send CSI hints, and the specification leaves that entirely up to clients.

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

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

  8. ralphm

    Now, if there was a dedicated protocol to explicitly relay user activity stats, that'd be different.

  9. Ge0rG

    Yeah, but data collection is not solely about the original purpose of the data

  10. ralphm

    There is difference in processing for legitimate purposes, processing it for analytics, combining it with other data, etc.

  11. ralphm

    And then if you store it, there are also concerns around retention and deletability.

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

  13. Ge0rG

    This is getting similar to the discussion we had about the clarification of stored message content

  14. Ge0rG

    ralphm: I agree with that

  15. ralphm

    Well yeah, there, if you agreed that the server keeps an archive for you, then that's fine.

  16. ralphm

    And public channels have a clear way of finding this out before joining.

  17. Ge0rG

    ralphm: the question was whether the content is PII or even special category PII

  18. ralphm

    PII is an old term not valid for GDPR discussions. There, we have Personal Information, and that's broader than the US term.

  19. jonas’

    and article 9.1 stuff

  20. ralphm

    Personal Data, I mean

  21. Ge0rG

    ralphm: oh, I wasn't aware those are different things

  22. ralphm

    Ge0rG: oh yeah

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

  24. ralphm

    So often, just anonimising might not be sufficient.

  25. Ge0rG

    ralphm: the question was whether the content is Personal Information or even Special Categories of Personal Information

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

  27. ralphm

    In principle CSI just says: hold that thought until I say when.

  28. Ge0rG

    ralphm: but you know the client implementation from disco#info, and you can derive those things

  29. jonas’

    yes, but that is being actively evil

  30. jonas’

    purposes and such

  31. ralphm


  32. jonas’

    you *can* do it, but as long as you don’t, you’re fine

  33. ralphm

    E.g. not storing / logging it would be a good start

  34. ralphm

    In any case of doubt, by the way, talk to lawyers.

  35. jonas’


  36. jonas’

    lawyers are expensive

  37. Ge0rG

    ralphm: lawyers are there to _increase_ your doubt

  38. ralphm

    jonas’, Ge0rG seems concerned about corporations, they (should) have lawyers as well as data protection officers.

  39. ralphm

    Usually it is about three things: purpose, consent, and retention.

  40. ralphm

    I've learned that engineers, including myself, generally don't have sufficient legal knowledge to make proper assertions in this area.

  41. ralphm

    But I learned quite a bit over the last few years.

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

  43. jonas’

    except maybe daniel, because he might be able to afford a lawyer

  44. Ge0rG

    While being an engineer as well, I've been doing a large chunk of GDPR consulting in the last two years or so

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

  46. ralphm

    Ge0rG: I'm not saying you have to be a lawyer. I said 'generally' and 'when in doubt'.

  47. Ge0rG

    ralphm: right

  48. jonas’

    hooking into the silence: I was thinking that we might want to set up a mentoring process for first-time XEP authors

  49. jonas’

    and I’d volunteer right away to be a mentor to those

  50. jonas’

    my main issue is with how to present this

  51. jonas’

    and where

  52. jonas’

    i.e. how to make people make use of that?

  53. Seve

    How that would be? would it be a document with guidelines and so? (It is a very good idea by the way)

  54. ralphm

    Well, getting in contact with an Editor before/during submission seems like a good first step in general.

  55. Ge0rG

    jonas’: I'd suggest adding a paragraph for prospective authors at https://xmpp.org/extensions/

  56. Ge0rG

    maybe linking to a wiki page that you maintain, listing best practices and mentors

  57. ralphm

    XEPs 0143 and 0134 should be good starting points to highlight, as is XEP-0001.

  58. jonas’

    none of those is a good starting point

  59. jonas’

    sorry, but no

  60. ralphm


  61. jonas’

    they describe processes from the inside, not from the outside

  62. jonas’

    I think?

  63. jonas’

    something like that

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

  65. ralphm

    That doesn't make sense to me.

  66. ralphm

    How does it not matter?

  67. jonas’

    I’m trying to formulate what I mean

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

  69. Vaulor

    Aixo es el que vull veure

  70. ralphm

    Vaulor: English, please.

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

  72. jonas’

    none of that is, to my knowledge, clear from the XEPs you mentioned

  73. Seve

    Vaulor, hah, wrong tab, right? :D

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

  75. Vaulor

    Yup, sorry wrong tab indeed

  76. Ge0rG

    a "proper" page is fine with me

  77. ralphm

    Vaulor: 🙃

  78. ralphm

    jonas’: in any case: yay, go for it

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

  80. Daniel

    jonas’, what part about the process is unclear wrt to the reactions xep?

  81. ralphm

    Daniel: it is entirely unclear to me why it hasn't been accepted (yet?)

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

  83. jonas’

    right, I don’t think the rejection was made clear and public in the thread even.

  84. jonas’

    that’s something council should probably work on

  85. jonas’

    (or maybe the editor)

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

  87. Daniel

    jonas’, i'm personally not really under the impression that the authors (of that particular xep) need help with any of these points

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

  89. mathieui

    the council on reactions was one month ago, I think?

  90. ralphm

    Why was it on the agenda (item 5) for yesterday's meeting then?

  91. Daniel

    wasn’t that retractions?

  92. ralphm

    Oh wait that agenda was an older one. Sorry

  93. mathieui

    actually that was exactly one month ago

  94. ralphm

    I see now that Kev vetoed it

  95. Ge0rG

    don't confuse reactions, retractions and references with each other.

  96. ralphm

    I found the minutes of that meeting: https://mail.jabber.org/pipermail/standards/2019-August/036345.html

  97. Ge0rG

    this is where "post-factum mail tagging" could come in useful

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

  99. ralphm

    Well, maybe having explicit, separate, rejection notifications would help here. I thought we had that done before, or suggested, but I missed this.

  100. Kev

    Which is about as good as Council can do, I think.

  101. jonas’

    re XEP-0353: 15:17:20 dwd> I'm +1 for this. Seems widely deployed and sensible. Daniel claims otherwise on-list. Fight!

  102. ralphm

    Right, I am looking for that mail

  103. ralphm

    Oh, crap, it was buried in the thread of the initial submission. Sorry, Kev

  104. flow

    A pitty that we only require two implementations before a xep can advance only for 'final'

  105. ralphm

    flow: because we have that problem a lot?

  106. Daniel

    so reactions passed?

  107. ralphm

    Daniel: no

  108. flow

    ralphm: the problem that xeps advance without much implementation experience nor feedback? I think so

  109. ralphm

    flow: we were talking about accepting XEPs in the the first place.

  110. flow

    ralphm, I was responding to jonas' comment regarding xep353

  111. ralphm

    Which moved to Draft, right?

  112. mathieui

    Daniel, vetoed on list by Kev

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

  114. ralphm

    I don't see why that's a problem. I have concerns about XEP-0353, but it is not set in stone.

  115. ralphm

    flow: we do, it is called proto xep

  116. ralphm

    And also

  117. flow

    ralphm, I'd argue we do not

  118. Daniel

    ralphm, you can’t really edit a protoxep tho?

  119. Daniel

    or can I? maybe i should try

  120. flow

    Daniel, it's not really specified or at least promoted that you can

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

  122. flow

    I guess you could PR against XEPs in inbox

  123. flow

    But if this is encouraged then we should promote it more

  124. flow

    Otherwhise establish something like xmpp.org/extensions/protoxeps/my-kewl-new-xep.html

  125. flow

    where authors could PR against without much review

  126. Daniel

    because I actually wanted to edit the aesgcm uri scheme one

  127. Daniel

    so let me try that and see what happens

  128. flow

    go for it :)

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

  130. ralphm


  131. ralphm

    But again, I think in general most of this should happen in experimental.

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

  133. ralphm

    I believe the concern with reactions specifically is that seems undesirable to have this end up in production clients in its current state

  134. Daniel

    the expected quality for an experimental xep varies between councils and moods

  135. flow

    What if I want to develop a protoxep without submitting it right away? Could I simply PR it into inbox?

  136. ralphm

    Kev: I appreciate that of course, but the end result now is limbo?

  137. Kev

    Yes, I wasn't anticipating the authors not taking me up on the offer.

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

  139. ralphm

    flow: eh, that's a good question

  140. Daniel

    i'd implement reactions now if it weren’t for other problems in Conversations

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

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

  143. ralphm


  144. ralphm

    Daniel: even given the concerns?

  145. flow

    And why not raise the bar a little bit for experimental to not accept XEPs with issues *and* a solution?

  146. Daniel

    flow, that is an interesting question. probably stable home + discoveribility

  147. flow

    Daniel, well you could argue that stable home is already extensions/inbox/reactions.xml

  148. flow

    err .html

  149. flow

    And I'd say that it is a feature that it is, in its current state, not easily discoverable

  150. ralphm

    We've had tried discussion before, I think Experimental is that state, and adding another one just moves names around.

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

  152. 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'

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

  154. Daniel

    but if experimental is that state than reactions shouldn’t have been blocked?

  155. ralphm


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

  157. Daniel

    because it won’t be able to anyway

  158. Daniel

    and the attempt has other problems

  159. Daniel

    also 'experimental' comes with the warning of 'do not use this in production'

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

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

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

  163. mathieui

    flow, that’s kind of 367 though?

  164. mathieui

    (except 367 is not enough for reactions)

  165. flow

    mathieui, possibly, but I think it is broken

  166. flow

    mathieui, why is it not enough for reactions?

  167. Daniel

    ralphm, https://dino.im/xeps/reactions.html#business-id?

  168. ralphm

    indeed, XEP-0367 would need some work, and maybe a rename, but this was discussed here before as a possible basis.

  169. Daniel

    regarding (1)

  170. ralphm

    Daniel: is this a progression on the not-accepted specification

  171. ralphm


  172. Daniel

    ralphm, oh tbh i didn’t check

  173. ralphm

    Well, I don't think it is wise to discuss alternative documents that aren't somehow covered by our IPR

  174. ralphm


  175. Daniel

    i wasn’t aware that the documents didn’t match

  176. flow

    Another argument to establish an I-D equivalent for XEPs

  177. Daniel

    that link was just the first one to shop up in my browser history

  178. mathieui

    flow, no support for updating or removing an element

  179. mathieui

    Daniel, the documents are strictly identical as far as I can tell

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

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

  182. Kev

    I wasn't expecting it to end up with the protoXEP being abandoned instead.

  183. Kev

    I thought the outcome would be that the XEP got accepted a fortnight later, in a much better state.

  184. Daniel

    ralphm, sure. there are things that can and should be improved.

  185. mathieui pings larma about it

  186. ralphm

    Without insight into the author's intentions, I'm not sure if it has already been abandoned. Maybe vacation got in the way.

  187. Daniel

    on the other hand we also have experimental XEPs that are literally 60% TODOs

  188. Ge0rG

    Kev: in that case you should have just moved on with your offer to make a PR

  189. ralphm

    Having at least a response on Kev's extensive notes would help.

  190. ralphm

    Kev waiting for a response seems reasonable.

  191. Kev

    Ge0rG: Hindsight is a harsh mistress.

  192. Ge0rG

    flow: IIRC, sending a PR against inbox will mean that the editors trigger a resubmission.

  193. Ge0rG

    Kev: indeed.

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

  195. Daniel

    using attachments?

  196. Daniel

    (or just link me to the 'offer')

  197. ralphm

    Kev: do you foresee a clearing in your time? I'd happily collaborate on this.

  198. Ge0rG

    If I got the authors right, they talked to Sam about 0367 and got told that it's not acceptable for Reactions.

  199. ralphm

    Maybe they should instead come here or on list.

  200. ralphm

    Including Sam

  201. Ge0rG

    ralphm: maybe this is one of the non-obvious things for new authors that jonas’ was talking about earlier

  202. ralphm


  203. jonas’

    and I don’t think all of those non-obvious things can be written down

  204. jonas’

    but someone who has more knowledge of the internal workings of the XSF and the process will be quickly able to answer it

  205. jonas’

    and it’d be good to have a person assigned to each newbie-proto-xep who’ll deal with that type of questions

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

  207. ralphm

    Also, Message Attaching, References, etc. all need work.

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

  209. Ge0rG

    ralphm: what do you see missing from Message Attaching?

  210. Ge0rG

    Kev: let's hope nobody rejects that ~= identical XEP on the grounds of it being duplication of Attaching, then.

  211. ralphm

    Ge0rG: particularly around how we all store and retrieve these things from archives

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

  213. Zash

    Maybe gather everyone at a Summit and reinvent all these message relation things from first principles? 🙂

  214. Kev

    I deliberately said 'ask', not 'reassign', yes.

  215. Ge0rG

    ralphm: this is a hugely complex topic that's absolutely deserving its own XEP

  216. ralphm

    Ge0rG: yes, but if we don't start to address it early on, this might be a lot of pain

  217. Ge0rG

    ralphm: we are already half-in into that pain.

  218. ralphm

    Ge0rG: I don't think we've barely scratched the surface.

  219. Ge0rG

    ralphm: we have north of four different ways to reference one message from another.

  220. ralphm

    Zash: I've been toying with the idea of having a spec-writing-sprint on this indeed. The Summit is too far out.

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

  222. Ge0rG

    (I mean: the difference between having four vs five)

  223. ralphm

    well, isn't the text about ids in reactions not a copy-paste from XEP-0353?

  224. ralphm

    This alone is reason to think that one should use the other

  225. Ge0rG

    ITYM 0367

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

  227. ralphm

    I meant 0367 of course

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

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

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

  231. Ge0rG

    (do I need to draw ASCII art?)

  232. mathieui

    Ge0rG, but then having it inside will break the LMC fallback for clients not implementing it

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

  234. Ge0rG

    mathieui: right. bummer.

  235. Daniel

    to be fair the introduction of 367 even mentions emojis. so it seems like a somewhat good fit?

  236. Daniel

    and creating Message Attaching 2.0 that is 95% identical might only be more confusinig

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

  238. Ge0rG

    ralphm: ^

  239. 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!

  240. ralphm

    Ge0rG: oh, you mean attaching with a body?

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

  242. Daniel

    i think the issue occurs when lmc uses attach-to

  243. Daniel

    then you don’t know which attach-to is which

  244. ralphm


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

  246. ralphm

    I'm not sure if I'd like to see multiple attach-to elements in one stanza ever.

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

  248. ralphm

    LMC (etc) are basically versioning on an original message

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

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

  251. Ge0rG

    Daniel: but if you stuff the payload into the attach-to element, you lose backward compatibility.

  252. Daniel

    well for some things that's good

  253. Daniel

    because for reactions we don’t want a fallback anyway

  254. Ge0rG

    ralphm: what about delivery receipts or read markers? Are those suitable for <attach-to>? How many different reference mechanism are actually needed?

  255. ralphm

    XEP-0367 currently also says you can't have multiple.

  256. Ge0rG

    Daniel: who is "we"?

  257. Daniel

    Ge0rG, in that case the majority of people on the mailinglist

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

  259. mathieui

    Ge0rG, most people who can envision how hellish a reactions fallback would be

  260. larma

    Because both LMC and Message Attaching should be attached in the thin client MAM usecase

  261. Ge0rG

    > Ge0rG, in that case the majority of people on the mailinglist 🤷

  262. Daniel

    putting the stuff inside the attach-to element would also limit what a MAM archive has to store

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

  264. Ge0rG

    ralphm: yeah, so what's the cut-off point for use-case specific syntax vs. using a general attach-to vehicle?

  265. Ge0rG

    The current Attaching XEP is _obviously_ good for everything that appends visible content to another message.

  266. ralphm

    And MAM wise, you probably want entirely different handling between: 1) LMC/editing, 2) reactions, 3) References/SIMS, 4) receipts, 5) markers.

  267. Ge0rG

    but then again, a receipt checkmark icon is also visible content attached to the message.

  268. ralphm

    Ge0rG: I see the latter more as meta data than an attachment

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

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

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

  272. Ge0rG

    Daniel: is conversations making any use of per-contact-device markers/receipts?

  273. ralphm

    pep.: I said I agreed with that indeed.

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

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

  276. Ge0rG

    the interesting thing is when you put content inside of the <attach-to>

  277. Ge0rG

    ...and if you read today's discussion in here, it IS hard.

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

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

  280. Ge0rG

    pep.: a ref to that quote please?

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

  282. Ge0rG

    ralphm: so we need four different ways to reference messages, for the purposes of Future MAM?

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

  284. ralphm

    pep.: i.e. once a document is in the process, we rely on general consensus with guidance by council.

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

  286. ralphm

    Ge0rG: and yes, MAM handling itself is going to be much more involved than the currently naive single dimension.

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

  288. ralphm


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

  290. Ge0rG

    but not if you plan the things you outlined above

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

  292. pep.

    (Still catching up with messages on this channel)

  293. Ge0rG

    pep.: the last mails from Sam were purely sarcastic, it seems

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

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

  296. Ge0rG

    larma: this is an interesting point in the current discussion ralphm and I have

  297. pep.

    Ge0rG: mails from larma

  298. ralphm

    larma: what is SCE again?

  299. jonas’

    stanza content encryption

  300. Ge0rG

    ralphm: Stanza Content Encryption

  301. pep.


  302. Ge0rG

    pep.: those don't count.

  303. Ge0rG

    pep.: I'm looking for a statement from Sam, directly.

  304. pep.

    Ge0rG: same

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

  306. Ge0rG

    ralphm: you can't encrypt for the MAM store

  307. ralphm

    Ge0rG: yes of course

  308. Ge0rG

    This is conflicting with "encrypt all the things"

  309. ralphm

    Ge0rG: I'm not sure if having some bits encrypted and some not is a useful thing.

  310. Ge0rG

    ralphm: nobody said it would be easy.

  311. ralphm

    I.e. I don't think having server side archiving mixes with e2ee

  312. Ge0rG

    ralphm: it has to mix

  313. ralphm


  314. Ge0rG

    you could argue that you can't have a "thin e2ee client", but I think there are people doing OMEMO in Converse.js

  315. larma

    People will want to a) have e2ee and b) use MAM and thin clients. We must make sure that it works.

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

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

  318. Ge0rG

    ralphm: we have to accept what the users want and try to make it work out

  319. ralphm

    larma: how, bar the protocols itself, do you think this is achievable?

  320. Ge0rG

    we already are the blackberry of instant messengers.

  321. ralphm

    Ge0rG: I haven't got any offers for narcotics yet.

  322. Ge0rG

    ralphm: didn't you complain about spam just some days ago?

  323. ralphm

    yes, no narcotics :/

  324. Ge0rG

    I'm sure there were also offers for illegal drug markets.

  325. Ge0rG

    maybe you couldn't read them because they were encrypted with Russian.

  326. ralphm


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

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

  329. Daniel

    i rarly get asked for sce

  330. pep.

    Daniel: do they even know?

  331. ralphm

    larma: you mean that the act of referring is outside the encryption, but not the payload of said referencing

  332. pep.

    What kind of user tells you that

  333. larma

    ralphm, exactly and also the reason for referencing should not be mentioned outside

  334. ralphm

    larma: that might theoretically work, but it is probably a pain for proper handling of all the use cases I mentioned above.

  335. Ge0rG

    > ralphm, exactly and also the reason for referencing should not be mentioned outside this conflicts with Smart MAM

  336. ralphm

    SMAM :-P

  337. Ge0rG

    ralphm: maybe a useful degradation would be "store all the grouped message in bulk, deliver them in bulk"

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

  339. ralphm

    Ge0rG: I guess.

  340. Ge0rG

    Given that meta-data kills, XMPP E2EE is a huge scam.

  341. Daniel

    other than that i reckon it is not 'unknown' that the existing e2ee methods don’t do sce

  342. larma

    Ge0rG, Not sure how smart your MAM should be, but if your server-side information is limited, obviously you cannot be super-smart

  343. Daniel

    Ge0rG, i'd argue that the meta data that kills is mostly the who with whom

  344. Daniel

    and not 'has read a message'

  345. larma

    Also IMHO this is mostly hypothetical, the smart MAM will probably be adopted as fast as MIX

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

  347. Ge0rG

    larma: normally I'm the one with the pessimistic adoption rate estimations

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

  349. Ge0rG

    yeah, can't we get our own cryptocurrency billionnaire sponsor?

  350. Ge0rG

    I'd be glad to work on XMPP full time as well.

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

  352. ralphm

    And just to be sure, the reference itself should also be inside the encypted payload, to prevent spoofing, right?

  353. Ge0rG


  354. ralphm

    Anyway, I am still curious: in which cases would one have to reference two different messages from one stanza?

  355. Ge0rG

    a type-less reference outside, and a typed reference (LMC / reaction / ...) inside

  356. Ge0rG

    ralphm: the current go-to example is an LMC of a message with a reference

  357. ralphm

    Yeah, I don't see that use case.

  358. Ge0rG

    why not?

  359. Ge0rG

    because you want a dedicated protocol for LMC?

  360. ralphm


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

  362. ralphm

    Other than, maybe retraction, which is still not LMC

  363. Ge0rG

    technically, LMC and retraction are very close

  364. Ge0rG

    except for the moderator use case

  365. ralphm

    But for retraction you can just refer to the thing you are retracting. You don't need the whole thing.

  366. Ge0rG

    so you mean a retraction lacks a payload?

  367. ralphm

    I think so

  368. ralphm

    Like in PubSub

  369. Ge0rG

    I'd actually like to see retraction re-worded as a payload-less LMC, but I see there are reasons against that

  370. ralphm

    I'd like edits instead of LMC

  371. Ge0rG

    OTOH, we could extend LMC with a @by attribute denoting who did the edit

  372. ralphm

    and retractions separate

  373. Ge0rG

    I'm using LMC as a synonym for arbitrary edits. The "last message" limitation is the worst thing about that XEP

  374. ralphm

    let's kill it then

  375. Ge0rG

    If I had unlimited time, I'd rewrite LMC into "Message Edits"

  376. Ge0rG

    ralphm: what would you do differently with "Message Edits", in comparison to LMC?

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

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

  379. ralphm

    eh. retraction

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

  381. ralphm

    Moderators should surely be able to retract others' messages

  382. ralphm

    Ge0rG: I think all of this discussion hinges on figuring that out

  383. Ge0rG

    ralphm: I think it's useful to have editing of messages by moderators.

  384. ralphm

    Ge0rG: why?

  385. Ge0rG

    You could remove expletives for example. mod_pastebin could be implemented in terms of editing.

  386. ralphm

    I think that opens quite a can of worms

  387. ralphm

    Either a message is acceptable, or it isn't.

  388. Ge0rG

    Because we have a good server side mechanism to enforce what's acceptable, that can be used by moderators?

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

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

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

  392. Guus

    Is having the XSF not wanting to deploy specific features reason to prevent a XEP that implements exactly that feature from being standardized?

  393. Guus

    I'm not liking content editing by third parties either - but should we therefor not allow such a XEP to exist?

  394. ralphm

    Reading back, it still isn't clear to me how Sam thinks XEP-0367 should be used, and how Council wants something else.

  395. Guus

    I'm not liking content editing by third parties either - but should we therefor not allow such a XEP to be standardized?

  396. ralphm

    Guus: well, I don't think it is wrong for Standards JID to have an opiniated process.

  397. ralphm

    Guus: we deal with privacy and security concerns, so maybe yes that could mean we won't standardize a particular feature.

  398. ralphm

    Guus: and that in turn might mean that you'd have to have a private extension, or write an IETF draft

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

  400. ralphm

    flow: I have the same feeling about metadata

  401. flow


  402. matkor

    Hi! By who's lack of activity https://xmpp.org/extensions/xep-0396.html is Deferred?

  403. ralphm

    matkor: usually this means the Author, but in principle 'all of us'

  404. flow

    matkor, everyone. As in, someone just needs to work on the XEP

  405. flow

    matkor, but why do you bother about it being deferred?

  406. flow

    if you implemented it, then please provide feedback

  407. flow

    ideally that leads to an update of the XEP, un-deferring it

  408. flow

    Re attach-to/reference: Why not simply have a <reference-ohter-stanza/> without childs which references at most one stanza regarding one concern?

  409. flow

    s/at most/exaclty/

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

  411. flow

    matkor, that's the question we ask yourselfs here daily: What is the right way :)

  412. matkor

    Seems Conversation uses XEP-0396 with success I wondered why gajim is lacking it.

  413. Ge0rG

    flow: "references exactly one stanza regarding one concern" so what do I do if I want to reference two stanzas regarding different concerns?

  414. flow

    matkor, the answer is usually because nobody implemented it

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

  416. flow

    Ge0rG, send two stanzas

  417. ralphm

    Ge0rG: still like to see that use case

  418. flow

    or maybe it is not clear to me what "want to reference two stanzas regarding different concerns" means

  419. Ge0rG

    flow: what, if the same content relates to two stanzas in different ways?

  420. flow

    Ge0rG, send two stanzas?

  421. flow

    also, please provide a more-or-less real-world example

  422. matkor

    flow, sure, but there are usually reasons why sth is not implemented like a) there is better way, b) sth is obsolete

  423. flow

    otherwise it is hard to reason about it

  424. ralphm

    matkor: c) nobody has found the time, yet

  425. flow

    matkor, the most common reason is because nobody did it

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

  427. flow

    Ge0rG, edit as in? LMC?

  428. Ge0rG

    flow: yes

  429. Ge0rG

    flow: see my discussion with ralphm above regarding "edit" vs LMC

  430. flow

    Ge0rG, the LMC that message that is attached-to another message with the yet-to-be-invented generic attach-to mechanism

  431. flow

    *then LMC that

  432. Ge0rG

    flow: but I want LMC to use the generic attach-to mechanism!

  433. Ge0rG

    it's not generic if it doesn't cover LMC

  434. flow

    then bump LMC to do so

  435. Ge0rG

    flow: but then I have double references.

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

  437. flow

    Ge0rG, double references?

  438. Ge0rG

    flow: two references in one message

  439. flow


  440. ralphm

    larma: that is a good use case indeed

  441. Ge0rG

    flow: 1) this is an edit of my message X; 2) this is a reaction/attachment/whatever to message Y

  442. Ge0rG

    ralphm: I'm sure Message References does cover that one ;)

  443. ralphm

    Ge0rG: except if you want to use XEP-0367 for doing referring to another messages.

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

  445. flow

    the mail protocol allows it, but is very seldom used

  446. Ge0rG

    flow: in the context of Message References, you can also reference users, URLs, etc.

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

  448. flow

    Ge0rG, probably, but that is not the context discussed here

  449. Ge0rG

    flow: if only we had thread references.

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

  451. larma

    flow, so you are proposing to change from "seldom used with XMPP" to "I use email instead because XMPP doesn't support it"

  452. Ge0rG

    ralphm: but only because 0372 lacks support to reference messages ;)

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

  454. Ge0rG

    flow: I've given an example above.

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

  456. flow

    be it xmpp or mail

  457. flow

    and I believe this to be true for the majority of users

  458. Ge0rG

    I was multiple times in a situation where I wanted to reply to multiple mails from subthreads of the same thread. On standards@.

  459. Ge0rG

    Arguably, I'm not the majority of users.

  460. flow

    Ge0rG, then why didn't you do?

  461. ralphm

    I think larma is more like including hyperlinks

  462. ralphm

    larma's example

  463. Ge0rG

    flow: because I had no idea how.

  464. larma

    flow, But what does that imply? That we shouldn't be able to handle it on a technical level?

  465. flow

    larma, I don't believe the increased complexity is justified. Please note that I am strictly talking about referencing stanzas

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

  467. 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…

  468. larma

    `<message><body>look at that previous message</body><reply-to id=A /><reference-back-to id=B /></message>`

  469. ralphm

    I.e. you can still have a URI that points to an XMPP message, or a tweet, or a something else.

  470. flow

    that that URI potentially would not be processed by the message archive in any way, which is probably fine

  471. ralphm

    larma: we don't have reply-to, really, we have threads

  472. ralphm

    flow: indeed

  473. Ge0rG

    but nobody uses threads, so we should replace them with generic references.

  474. ralphm

    god no

  475. larma

    ralphm, we don't have X so we should never ever support it

  476. Ge0rG

    but if we do that, we have a convincing example of why it makes sense to have two references in one message.

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

  478. Ge0rG

    references and References.

  479. flow

    although I am not sure if we need the one-or-more semantic references ever

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

  481. Kev

    It's probably not true, but it's pretty close to it.

  482. ralphm

    In the end this discussion is about the tightness of coupling

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

  484. Ge0rG

    flow: I disagree on this one. We should take into account the long-term delelopment of the protocol when adding new XEPs

  485. Ge0rG

    Otherwise, we end up with MAM and Carbons.

  486. 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?"

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

  488. Kev

    Which is why I'm quite happy with the idea of keeping attaching and references distinct.

  489. Kev

    Be it the two XEPs, or two different annotation types in a single XEP.

  490. flow

    Kev, does that matter much?

  491. Ge0rG

    Kev: I'm not quite sure what you mean by "follows on"

  492. Kev

    Yes, and I realise there's essentially three reference types, as you say that.

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

  494. Ge0rG

    Kev: three?

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

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

  497. Ge0rG

    In-Reply-To is what threads are for. But isn't a Reaction also In-Reply-To?

  498. Kev

    I am happy to limit 372 to the second type. I originally intended to cover everything, but I'm not dogmatic about that.

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

  500. Ge0rG

    ralphm: I'm trying to understand all the implication, and maybe to find a good way forward.

  501. Ge0rG

    I think that the trinity proposed by Kev is a good approximation

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

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

  504. Kev

    ralphm: There are two halves of that type of reference, yes.

  505. ralphm

    for 1) you need something like attachments, 2) URIs are great

  506. Ge0rG

    ralphm: for 1 you need what's written in 0372

  507. Ge0rG

    unless you want to make the marking-up a separate message from the original text

  508. Kev

    Ge0rG: Which I think has value.

  509. Ge0rG

    in which case, you attach-to the original message a set of reference-markups

  510. Kev

    e.g. a MUC service that annotates a message once it's fetched an async resource.

  511. ralphm

    Ge0rG: this is about 'anchor' v.s. 'uri'

  512. ralphm

    Ge0rG: we can replace 'anchor' with 0367.

  513. Ge0rG

    ralphm: now I'm totally confused.

  514. ralphm

    And then make it easier to mark up multiple parts of the text without having to repeat the anchor.

  515. 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'

  516. ralphm

    Ge0rG: a link has two parts: the text you want underlined, the URI you want to jump to. Clear?

  517. Kev

    Let's see if I can avoid distraction long enough to gist some example thoughts.

  518. Ge0rG

    5 uri='xmpp:juliet@capulet.lit'/>

  519. Ge0rG

    ralphm: so 2+3 is the anchor, and 5 is the uri

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

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

  522. ralphm

    Ge0rG: yes

  523. ralphm

    The former is section 3.2, the latter is 3.4.

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

  525. Ge0rG

    Something like this maybe?

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

  527. Ge0rG

    ralphm: wwhen do you need two different anchors?

  528. ralphm


  529. Kev


  530. ralphm


  531. Ge0rG

    ralphm: it's not long ago that you argued this would never be needed.

  532. Ge0rG


  533. Kev

    Ok, I'm suggesting we could do something like this, which is an advancement of 372/367

  534. Kev

    I think it's what Ralph's describing.

  535. Kev

    But if not, I've not understood and would like to :)

  536. Kev

    attach-to is the thing that could be 367, or something like it.

  537. ralphm


  538. Ge0rG

    Kev: the metatext inside your gist is confusing.

  539. Kev

    reference is the thing that's 372-ish.

  540. ralphm


  541. Ge0rG


  542. Ge0rG

    yes to what, actually?

  543. Kev

    Ge0rG: Which bit of metadata? Happy to update the list, I'm trying to balance brevity and clarity.

  544. ralphm

    a confirmation of Kev's interpretation of me

  545. Kev

    I guess I should add a reaction to that too, hang on :)

  546. ralphm

    Kev: do you have an opinion on nesting stuff inside attach-to v.s. sibling?

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

  548. Ge0rG

    Kev: what do you think of the XML I posted above?

  549. Ge0rG

    it would also solve ralphm's issue with multi-anchoring

  550. Ge0rG

    and it would solve the issue with "dumb" MAM grouping.

  551. ralphm

    I don't have an issue with multi-anchoring, we should not have it.

  552. Kev

    ralphm: I do, I think it's nested.

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

  554. Ge0rG

    and you could do SCE with low effort:

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

  556. Kev

    Yes, I think your 12:04 XML is roughly equivalent to what I pasted in intent.

  557. ralphm

    Kev: but at most one, right?

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

  559. Ge0rG

    okay, "low effort" actually means you need to extract attach-to skeletons

  560. Kev

    Ah, hi larma.

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

  562. ralphm

    larma: that is a good point, clients would need to check for this

  563. Kev

    https://gist.github.com/Kev/675475f30933b6d4f63bc9fce35bd29a updated

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

  565. flow

    larma, good point

  566. Kev

    https://gist.github.com/Kev/675475f30933b6d4f63bc9fce35bd29a updated again

  567. larma

    Ge0rG, why is the body outside the attach-to? looks wrong to me

  568. Ge0rG

    larma: because of backward compatibility to pre-LMC clients

  569. larma

    But semantically what you wrote is "attach the lmc marker to the message and have a message with this body"

  570. Ge0rG

    the lmc-marker is meant to signify that.

  571. flow

    is backward compatiblity really something we should be concerned in this case?

  572. Ge0rG

    flow: yes.

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

  574. Kev

    I think, in as far as we do fallbacks at all, we might have to consider having duplicate content here.

  575. ralphm

    Kev: you last example, message 6, would have backwards compat issues

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

  577. ralphm

    Ge0rG: still want that more than one example.

  578. Ge0rG

    ralphm: just because we two can't come up with one, it doesn't mean there is none

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

  580. Ge0rG

    larma: good point

  581. Kev


  582. Ge0rG

    Kev: what's wrong with my <lmc-marker/>?

  583. ralphm

    larma: for reactions, retraction, you wouldn't point to two different messages in one stanza.

  584. Kev

    Ge0rG: Maybe just that I missed it in the flow.

  585. larma

    Kev, I totally dislike the duplication of the body for backwards compat

  586. Kev

    larma: Good, me too :)

  587. Ge0rG

    Kev: 12:12:49

  588. larma

    ralphm, that's for those that only point to one (attach-to, not references)

  589. Kev

    Ge0rG: That might work.

  590. Ge0rG

    ralphm: what about reaction retraction?

  591. Ge0rG

    larma: 0372-style references are a different topic

  592. Kev

    Ge0rG: https://gist.github.com/Kev/675475f30933b6d4f63bc9fce35bd29a ?

  593. ralphm

    Ge0rG: you can just retract the stanza of the initial reaction, like message 4 in Kev's example

  594. Ge0rG

    Kev: yeah

  595. larma

    Kev, that's implying that you can only change the body with LMC

  596. ralphm

    Yes, that's what it is for.

  597. Ge0rG

    ralphm: no, it's for any kind of payload.

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

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

  600. Kev

    You're both right.

  601. Kev

    Or all three.

  602. Kev

    You can replace any payloads, but not rewrite the logical-type of the stanza.

  603. Ge0rG

    Kev: rename the element to <message-edit/>

  604. Kev

    You mean s/body-is-edit/message-edit/?

  605. Ge0rG

    Kev: yes. or maybe message-is-edit

  606. Ge0rG


  607. Ge0rG

    Bike shedding!

  608. Kev

    These are details I feel don't need to be in a pseudo-exmaple.

  609. Kev

    What's really relevant, I think, is that the LMC instruction lives within the attach-to.

  610. Kev

    And that references can also live within an attach-to, as can reactions.

  611. Ge0rG

    And that we can have multiple attach-to elements with different payloads in one message!

  612. ralphm

    Why is that better than as a sibling (trying to get my head straight)

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

  614. ralphm

    Ge0rG: or we stop thinking we need multiple.

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

  616. Kev

    ralphm: Clear hierachy. Sometimes you have 'extra noise' in stanzas, and it's much more convenient to be clear which bits apply where.

  617. Kev

    Ge0rG: I don't yet understand the need for multiple attach-to in a single stanza.

  618. Kev

    And yes, what Ge0rG says about nesting, too.

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

  620. Ge0rG

    Kev: 0184 would have been so much better with multiple payloads

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

  622. flow

    Ge0rG, I am not sure that this means that it can't be implemented any more

  623. Ge0rG

    but nobody came up with the use case of offline message mass-acking

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

  625. flow

    I sure would require a ns bump

  626. Ge0rG

    flow: an ns bump and server-side conversion modules.

  627. flow

    point is, it is easy to go from a exactly-once to one-or-more semantic, but not the other way around

  628. flow

    or "easier"

  629. Ge0rG

    flow: or clients adding multiple versions of attach-to elements with different semantics into one message.

  630. Kev

    I'm not sure I'd say it was 'easy', but 'easier', yes.

  631. Ge0rG

    with the proposed semantics, is there a reason NOT to have multiple attach-to in one message?

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

  633. Kev

    Ge0rG: If everything is properly nested, no. But if we allow leakage outside the attach-to, kinda yes.

  634. flow

    Ge0rG: and if we ever go from a esactly-once to a one-or-more semantic, you can say "told you so"

  635. ralphm

    flow: and then file bug reports for clients that only hanlde one

  636. 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™

  637. flow

    "feature requests"

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

  639. Ge0rG

    Kev: "A receiving entity SHOULD be able to process multiple attach-to payloads"

  640. flow

    Ge0rG, I don't see how parsing is the heavweight thing yo'd have to change here

  641. Kev

    Ge0rG: That's the worst of all worlds, isn't it? :)

  642. Ge0rG

    Hey, I could edit all my messages to the same text with one message!

  643. Ge0rG

    flow: not parsing but interpreting.

  644. ralphm


  645. ralphm

    That's exactly what I want to prevent.

  646. Ge0rG

    flow: `AttachTo message.getAttachToPayload()` vs. `List<AttachTo> message.getAttachToPayloads()`

  647. flow

    implementing interpreation of exactly-once is probably way easier than one-or-more

  648. ralphm

    We've removed batch stuff in several protocols, like pubsub.

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

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

  651. Ge0rG

    larma: what about <attach-to id=3><ENCRYPTED/></>

  652. larma

    Ge0rG, that would be the logical consequence, but then this is going to be terrible with legacy fallbacks

  653. pep.

    Kev: btw, nit (but not really), you don't need the "@" if you have References type mention.

  654. Ge0rG

    or rather: <attach-to id=3><external-sibling name="ENCRYPTED" ns="urn:xmpp:sce:0"/></>

  655. pep.

    (More garbage in body is never really welcome)

  656. Ge0rG

    and <external-sibling/> is a reference to the element name and xml:ns of the external sibling. MAXIMUM FLEXIBILITY!

  657. ralphm

    pep: but it might be what the user typed

  658. larma

    `<message><attach-to id=A><ENCRYPTED>actual</ENCRYPTED></attach-to><ENCRYPTED>fallback</ENCRYPTED></message>` definitely sucks

  659. Ge0rG

    ralphm: the user's client should replace `@user` with `user` and a reference, then! :P

  660. larma

    Ge0rG, how would you do if you attach multiple subblings?

  661. ralphm

    Ge0rG: if could

  662. Ge0rG

    larma: have multiple <external-sibling/> elements. Or just define the ns if they all share one

  663. ralphm

    Ge0rG: I meant 'it could'

  664. Ge0rG

    ralphm: I'm clearly thinking of the Slack UX here

  665. ralphm

    Ge0rG: Slack doesn't actually remove the @

  666. Kev

    Showing the @ is fairly usual in modern clients, I think.

  667. Kev

    But I don't think this is the most important of the discussed details :)

  668. ralphm


  669. ralphm

    I like how this is shaping up.

  670. Ge0rG

    Kev, ralphm: am I overengineering things with <external-sibling>?

  671. ralphm

    Ge0rG: yes

  672. Ge0rG


  673. ralphm


  674. Ge0rG

    A more pragmatic alternative?

  675. Kev

    I don't know, honestly.

  676. Kev

    I don't entirely understand why it needs to be alongside rather than nested, yet.

  677. Ge0rG

    I mean, the reference-tracking implications of that are really bad.

  678. Ge0rG

    Kev: the default would be nested

  679. ralphm

    I think having an empty attach-id is fine. If the encrypted payload is unwrapped, it can override it.

  680. Kev

    When would you external it?

  681. Ge0rG

    the only real use-case I see is message edits with legacy.

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

  683. Ge0rG

    Kev: it allows the archive to group related messages

  684. ralphm

    Kev: this was discussed arelier

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

  686. Ge0rG

    Kev: a thin E2EE client still benefits from that grouping

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

  688. ralphm

    I.e. retrieve all the encrypted attachments in one go

  689. Kev

    ralphm: But you can't have any grouping if there's no id, can you?

  690. Ge0rG

    Kev: what would <fallback/> mean?

  691. ralphm

    Kev: I mean no payload

  692. Kev

    Ge0rG: It'd be a plaintext that can be shown to the user if your client doesn't support that type of attachment.

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

  694. Ge0rG

    Kev: wait, what?

  695. ralphm

    Kev: <message to=room from=ralph id=4><attach-to id=3 /><ENCRYPTED><attach-to id=3><reaction>👍🏻</reaction></attach-to></ENCRYPTED></message>

  696. ralphm

    Kev: MAM can know that this thing belongs to 3, but the real thing is inside

  697. Kev

    ralphm: Yes, that seems arguably ok. That's not an empty id though :)

  698. ralphm

    I didn't say empty id

  699. Kev

    "I think having an empty attach-id is fine" :)

  700. ralphm

    oh, I did

  701. ralphm


  702. Kev

    If you didn't mean an empty attach id there, I don't know what you meant :)

  703. ralphm

    See, now I need edit

  704. Kev

    But yes, empty attach-to other than the id seems reasonable.

  705. Kev

    Suboptimal, but the best you can get if you want encrypted payloads.

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

  707. Ge0rG

    larma: could you please reformat your messages for the XML to begin at new lines, and maybe have some more structure?

  708. Kev

    I don't think it's compacted, no.

  709. ralphm

    What do you mean compacted?

  710. larma

    ralphm, for the usecase of thin client MAM

  711. larma

    (which seems to be the main use-case of all of this after all)

  712. Kev

    The attach-to lives in its own right, linked to the first message, rather than replacing the message itself.

  713. Kev

    So you'd be able to query the attachments of a message through SMAM.

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

  715. Kev

    But, by default, when requesting through MAM you'd not get them.

  716. Kev

    Wait, what? :)

  717. Ge0rG

    ralphm: also vice-versa? When you query for an attached message, to receive the original first?

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

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

  720. ralphm

    (like in Slack, you only see the counts, until you hover over them)

  721. Ge0rG

    but that means you need to deliver a map(reaction -> count)

  722. ralphm


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

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

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

  726. ralphm

    Kev: oh, MAM is a going to be quite another topic, indeed

  727. Kev

    larma: I think we do have semantic meaning of the children of attach-to.

  728. Ge0rG

    larma: but we actually _want_ to have semantic meaning for the children

  729. Ge0rG

    just not generally.

  730. Ge0rG

    the two exceptions being E2EE and legacy Edits

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

  732. Kev

    pep.: And thus isn't worth discussing at the moment :)

  733. pep. still trying to catch-up with what's been said in here

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

  735. Ge0rG

    larma: oh, of course it would rely on the generic attach-to feature

  736. Kev

    Sorry, why isn't SMAM using attach-to?

  737. Ge0rG

    it would just make better use of it

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

  739. 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 />`

  740. Kev

    But it doesn't /need/ to understand what reactions mean, does it?

  741. ralphm

    larma: the idea is definitely that a MAM server with knowledge about attachments, will have a more efficient storage retrieval.

  742. Kev

    There may be value in it doing so, but it doesn't fall apart if it doesn't.

  743. ralphm


  744. larma

    Kev, If it wants to build a map(reaction -> count) as suggested by Ge0rG it needs to understand

  745. Kev

    Yes. If it wants to be very smart, it can (and that is a good thing).

  746. ralphm

    Yes, it would be a discoverable feature.

  747. Kev

    But a somewhat-less-smart option is also available.

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

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

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

  751. Kev

    There's a hierachy of smarts, yes, if you want to call them GMAM and SMAM.

  752. Kev

    So SMAM is an improvement on GMAM is an improvement on MAM.

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

  754. Kev

    Do I need to make another gist once I've thrown some lunch in the oven?

  755. ralphm


  756. ralphm

    Doing the same

  757. ralphm

    Hmm bapao

  758. Kev

    This is very much not what I needed to get done today!

  759. ralphm

    Kev: yes you did. Your boss may complain to me.

  760. ralphm

    Also thank you

  761. larma

    I'd like to see an example of a message attachment being edited

  762. Ge0rG

    speaking of gists https://gist.github.com/ge0rg/a255cb521e45bbcb89573aa3218f0cd5

  763. ralphm

    larma: I don't really

  764. Ge0rG

    is that a valid summary of today's discussion? ^

  765. Kev

    "Can be sent by anyone" - unclear to me, more thought needed.

  766. ralphm

    larma: I'd rather see retraction and then a new one

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

  768. Kev

    "i.e." - you mean "e.g." ;)

  769. Kev

    "an without a payload" - missing some words, I think.

  770. Kev

    But yes, I think that's pretty close to a summary, and is useful to capture, thanks Ge0rG.

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

  772. Kev

    I don't believe retraction should be an attachment.

  773. Kev

    Because it has different semantics from attachments, for exactly this reason.

  774. ralphm

    Indeed. And retractions should be consolidated by the server

  775. Kev

    Ah, are we talking about retracting an attach-to, or retracting a source message?

  776. ralphm

    both, I suppose

  777. Kev

    I think they're very different.

  778. larma

    Kev, so you'd want always special handling for retraction, even in GMAM. Obviously makes sense in SMAM

  779. larma

    In case of SCE, do we encrypt the retraction element?

  780. ralphm

    Kev: they are, but the protocol doesn't have to be

  781. Kev

    ralphm: Yes, it does :)

  782. Kev

    Or, rather, makes a lot of sense to be.

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

  784. Kev

    Because I don't think that retracting attach-to by the id of the carrying stanza is entirely sensible.

  785. ralphm


  786. ralphm

    (is there a way for Gajim to show typing notifications in MUCs?)

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

  788. larma

    I agree that one shouldn't reference attach-to messages at all

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

  790. ralphm

    I was thinking more about: `<message><retract id='...'/></message>` for both.

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

  792. Kev

    And I also believe that storing attachments as attachments is probably easier than storing them as messages.

  793. ralphm

    Kev: yeah, we talked about dimensions before, and I'm not sure yet what the MAM protocol should look like.

  794. larma

    Kev, but often the message containing the attachment has relevant information, like the person that attached the message

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

  796. ralphm

    But semantically, calling a retraction an attachment is a bit odd.

  797. larma

    Matrix does the same IIRC 😀

  798. Kev

    ralphm: Yes, I would be happiest with just <message><retract...></>

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

  800. ralphm

    pep.: didn't I say we would have the ability to retrieve all the things?

  801. Kev

    larma: Yes, there's some metadata involved.

  802. Kev

    We did talk about all this at the summit, I wonder if any of it was captured in the minutes.

  803. ralphm


  804. ralphm

    Kev: if you'd be happier with my example, what is the problem with it then?

  805. ralphm

    Kev: the lookup?

  806. Kev

    Your example was to retract attach-to message wrappers in the same way as to retract messages, wasn't it?

  807. Kev

    I'm certainly not happier with that.

  808. Kev

    I'm happier when messages are retracted in one way, and attach-to retracted in another.

  809. ralphm

    So like we have retract item and delete node in pubsub?

  810. Kev

    Somewhat, yes.

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

  812. pep.

    ralphm: OK i right have misread

  813. ralphm

    No worries. Things were going FAST

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

  815. MattJ

    You had to be there

  816. Ge0rG

    You want message retraction to explicitly use a different mechanism than Attach-To? What about Message Edits, should that stay Attach-To?

  817. Zash

    Which direction does the relation go?

  818. Ge0rG

    Zash: the new message references the old message

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

  820. Zash

    But does the new message belong to the old message or the reverse?

  821. Ge0rG

    can we leave the philosophical questions for later, please, and focus on the protocol?

  822. nyco


  823. Guus


  824. ralphm


  825. Seve

    Test passed

  826. Guus

    we meet?

  827. nyco


  828. MattJ

    Oh wow, it's Thursday again :/

  829. Guus

    Welcome to my thoughts, 10 minutes ago.

  830. Guus

    (only because I got a calendar reminder 😉 )

  831. ralphm

    0. Welcome

  832. ralphm

    Hope everybody is reconnected, there was a strange disconnect with xmpp.org from here.

  833. Guus

    I've seen everyone say something.

  834. Seve


  835. MattJ


  836. ralphm


  837. ralphm

    1. Minute taker

  838. Guus

    assuming we can't find someone from the floor, I'll do 'm this time

  839. ralphm


  840. ralphm

    2. Badges

  841. nyco


  842. ralphm

    I have reached out to mray. He responded and asked the following:

  843. 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?”

  844. ralphm

    Who can create such a list?

  845. nyco

    other submissions did that, no?

  846. Guus

    combinations of what, exactly?

  847. nyco

    each requirements

  848. Seve

    Levels of compliance I guess

  849. ralphm

    All combinations of thingies to appear in the badges

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

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

  852. Guus

    so, we need each combination of Category with Level, and add a year / edition to it?

  853. Guus

    Although Core/Core 2019 seems weird.

  854. nyco

    2019 would be cool

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

  856. ralphm

    or somesuch

  857. Guus

    I'll wrap up a list

  858. ralphm


  859. ralphm

    Also thanks nyco fo sending the results out to the list.

  860. Seve

    Thank you guys

  861. nyco

    in a spreadsheet?

  862. ralphm


  863. ralphm

    3. Roadmap

  864. ralphm

    Apart from this huge discussion this morning, afternoon, I haven't gotten to this.

  865. ralphm

    Good progress on the former, though.

  866. ralphm

    4. AOB

  867. ralphm


  868. MattJ

    None here

  869. Guus

    I've got two

  870. Seve

    None here

  871. ralphm

    Guus: shoot

  872. Guus

    isn't it about time we organize new elections?

  873. nyco

    you mean Boris Jonhson?

  874. ralphm

    Usually Alex picks this up in September.

  875. Guus


  876. nyco

    missing id

  877. ralphm

    Next Guus?

  878. Guus

    2) I've been approached by https://openvoipalliance.org/ - they're interested in involving XMPP in this.

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

  880. Guus

    I'd like to see if there's benefit for us in actively becoming a partner in that effort.

  881. Guus

    (Thanks Alex)

  882. ralphm

    Guus: interesting. I see they already use XMPP and converse.js

  883. Seve

    I didn't know about it

  884. ralphm

    But yes, I'd be interested to know how they would like us to get involved.

  885. ralphm

    Guus: can you send me the e-mail? I'd be happy to follow-up.

  886. Guus

    what email? we're talking over XMPP. 🙂

  887. ralphm

    oh hehe

  888. Seve

    Niiice :)

  889. Guus

    I'll see if we can arrange for a groupchat of sorts

  890. ralphm


  891. ralphm

    Anything else?

  892. Guus


  893. ralphm

    5. Date of Next

  894. ralphm


  895. ralphm

    6. Close

  896. MattJ


  897. ralphm

    Thanks all!

  898. ralphm bangs gavel, and retroactively at the start of the meeting

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

  900. Seve

    Thank you for the meeting, glad to see all of you today

  901. nyco

    thx all

  902. nyco

    more glitches from the xmpp.org server?

  903. Zash


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

  905. pep.

    Zash: ip6 issues apparently? Says Ge0rG

  906. Ge0rG

    The connection hung. Looks like a kick against the tires helped.

  907. Ge0rG

    But then it dropped out again.

  908. Guus


  909. Guus


  910. Guus

    that was _not_ the copy/paste that I intended - sorry

  911. pep.


  912. Guus

    PEP mandates filtered-notification support

  913. Guus

    are all PEP services therefor always filtered, or can the feature go unused?

  914. Ge0rG

    Instant dick-pic upload!

  915. ralphm

    Guus: if you don't have the filtered notification, isn't it just regular pubsub on an account?

  916. Guus

    ralphm: pep adds other restrictions

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

  918. Guus


  919. ralphm

    Curious about the use case, though

  920. Guus

    Filtering is mandatory then, for pep

  921. Guus

    No use case. Bug hunting / code reviewing

  922. Zash

    Is it PEP if there's no filtered notifications, but instead dynamic presence based subscriptions?

  923. Guus

    Can clients even apply such configuration?

  924. ralphm

    Well the whole raison-d'être of PEP is not having to explicitly subscribe, so you have auto-subscription + filtering instructions via CAPS.

  925. ralphm

    Zash: there's a difference?

  926. Zash

    Not in practice

  927. ralphm

    Also not in theory?

  928. Zash

    Implementation detail I suppose

  929. ralphm

    Although I suppose you can think up another magic to get the notifications you want.

  930. Zash

    I'd like to have negotiation for the thing ejabberd did, where it'd just ignore your caps and send all notifications

  931. Zash

    expecting the receiving end to filter

  932. ralphm

    Really? That seems terrible.

  933. ralphm

    One of the use cases when PEP was created was User Tunes.

  934. Guus

    Not in an environment where you want everyone to get all notifications

  935. ralphm

    Initially people would just include that in presence directly.

  936. ralphm

    So you got presence updates, once per 3 min. for each user.

  937. Zash

    If you filter and fork notifications on the receiving server it works, and has some benefits like MAM potential

  938. Guus

    Which presumably is less IM, more IOTish

  939. Zash

    But this isn't what the PEP XEP says, so it leads to madness.

  940. Zash

    Hence why I'd like some opt-in between servers for that

  941. Guus

    Note that I was not looking for a XEP change, I was just trying to get clarification.

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

  943. ralphm

    Especially also for MIX.

  944. Zash

    ralphm, yeah

  945. Zash

    Not having to keep (a subset of) disco#info for remote entities seems like a nice thing to me as a server dev.

  946. ralphm

    As long as information is public that works. And identical between subscribers.

  947. Alex

    let's start our member meeting in 3 minutes

  948. Alex bangs the gavel

  949. Alex

    here is our Agenda for today: https://wiki.xmpp.org/web/Meeting-Minutes-2019-08-29

  950. Alex

    1) Call for Quorum

  951. Alex

    as you can see 36 members voted via memberbot. So we have a quorum

  952. Alex

    2) Items Subject to a Vote

  953. Alex

    new and returning members, you can see the application pages here: https://wiki.xmpp.org/web/Membership_Applications_Q3_2019

  954. Alex

    3) Opportunity for XSF Members to Vote in the Meeting

  955. Alex

    anyone here who has not voted yet?

  956. MattJ

    Erm, did I?

  957. Alex

    Memberbot is still online and will accept votes

  958. Zash

    Do it! Do it now!

  959. Alex

    MattJ: don't think so

  960. MattJ

    Ok, I'm on it

  961. Alex

    go for it

  962. jonas’


  963. jonas’

    I did vote, didn’t I?

  964. MattJ

    I'm done, probably made a massive difference to the outcome :)

  965. Guus

    I wonder if Santa is making notes for his naughty list.

  966. Alex

    MattJ: have your vote

  967. ralphm


  968. Alex

    anyone else?

  969. Alex

    looks like we have all votes

  970. Alex

    Will start counting the votes then

  971. Alex

    4) Announcement_of_Voting_Results

  972. Zash


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

  974. Alex

    all new and returning members are accepted

  975. Alex

    congrats to everyone

  976. Alex

    very high yes votes,, stands for high quality members

  977. Alex

    5) Any Other Business?

  978. jonas’

    or `yes | send_xmpp.py memberbot@xmpp.org` ;)

  979. jonas’

    congrats to the newly accepted members, Natalie Wirth and Marvin Wissfeld! :)

  980. jonas’


  981. jonas’


  982. Zash

    Congrats to everyone

  983. jonas’

    No AOB from me

  984. larma


  985. Alex

    just wanna mention that annual elections are coming up

  986. Ge0rG

    Alex: what's the timeline?

  987. Alex

    will work on the application page soon

  988. Guus

    Please consider running!

  989. Guus

    and/or motivate others to run.

  990. Ge0rG

    I need to ensure my campaign funding

  991. Alex

    last year the meeting was November 22nd

  992. Alex

    trying to stick close to that, so that board and council has same term length (12 month)

  993. Guus

    Sounds reasonable

  994. Alex

    see: https://wiki.xmpp.org/web/Meeting-Minutes-2018-11-22

  995. Ge0rG

    Natalie and Marvin can take over the Council now

  996. Alex

    6) Formal Adjournment

  997. Alex

    I motion that we adjourn

  998. Zash


  999. Alex bangs the gavel

  1000. jonas’


  1001. jonas’

    thanks, Alex

  1002. Alex

    thanks everyone

  1003. jonas’

    thanks everyone

  1004. Guus

    Thanks again, Alex.

  1005. Alex

    will send out mails tomorrow morning to members and update website and lists

  1006. pep.

    Thanks Alex

  1007. mathieui

    Thanks Alex