XMPP Council - 2022-01-19

  1. Ge0rG

    Today I'd like to AOB a bit about the three not-yet-rejected XEPs from two weeks ago. Sorry that I didn't manage to bring it up earlier, but there is a strategic issue I'm having that I'd like to discuss.

  2. daniel

    ack

  3. daniel

    Ge0rG: did you vote on those yet? I didn't record a vote from you

  4. daniel

    Which might be my fault

  5. Ge0rG

    daniel: no, I'd like to discuss before casting my votes

  6. larma

    Ge0rG, we can also do now if it needs me šŸ™‚

  7. Ge0rG

    larma: given what dwd wrote on the list, I'd like to veto fallbacks and have you merge it into 428.

  8. dwd

    It'd be very nice to have a clearer understanding of the consensus of the community on the fallback text manipulation bits. I'm quite prepared to be in the rough on that, but currently only me and larma appear to have any opinion at all...

  9. Ge0rG

    While XEP numbers are cheap, confusing developers with similarly named protocols that cover subtly different use cases is very expensive to us as a community.

  10. Zash

    As a ... server developer I just want to ... know whether to ignore <body> or not

  11. daniel

    > daniel: no, I'd like to discuss before casting my votes I think _technically_ the voting period ended yesterday. It's always two weeks, no? I think in this particular instance we can see past that but I think that as chair it's now somewhat my job to enforce the rules even though I'm not fully clear on them myself

  12. Ge0rG

    dwd: this, together with message references, sounds like a discussion for a day of summit

  13. Ge0rG

    daniel: IIRC it was 14 days after the day of the initial vote or some such.

  14. Zash

    Ge0rG, +1 (wrt confusing names being ungood)

  15. larma

    I totally get the point and I don't mind having it in 428, but I don't think it's subtle difference, given that this difference is what causes a lot of discussion

  16. daniel

    > daniel: IIRC it was 14 days after the day of the initial vote or some such. Right. But we are on day 15,no?

  17. Ge0rG

    larma: it's not the difference that causes the discussion but the general approach you suggested

  18. dwd

    daniel, Voting has usually been considered as two weeks inclusive; so the vote starts at Council Meeting 0, and ends at Council Meeting 2.

  19. Ge0rG

    larma: so having that discussion is worthwhile regardless of the XEP number it ends in

  20. larma

    Ge0rG, I mean the discussion about "alternative bodies", which is what this XEP is basically about ✎

  21. dwd

    larma, Actually, my main problem (as XEP author) is that there hasn't been discussion. Too much would be a problem I'd like to have.

  22. larma

    Ge0rG, I mean the discussion about "alternative bodies", which is what this ProtoXEP is basically about ✏

  23. Ge0rG

    Well, from a tactical point of view, I need to veto the XEP to ensure this discussion happens. šŸ˜‰

  24. daniel

    > daniel, Voting has usually been considered as two weeks inclusive; so the vote starts at Council Meeting 0, and ends at Council Meeting 2. dwd: OK fair enough. I actually think that makes sense. I just remember one occasion where I wasn't allowed to cast my vote in the second meeting anymore. Not that it matters anymore. But that made me unsure about the rules

  25. larma

    dwd, It's not like I don't understand your position and I think you understand my position. This is basically about opinions, I don't think any points can be added to the discussion (so, if it wasn't for me being directly involved, I wouldn't reply on this mailing list thread as well, so I can't blame anyone else for not doing it)

  26. dwd

    "usually". And of course, you're chair so you get to reinterpret the rules. :-)

  27. dwd

    larma, OK, but that suggests that nobody at all cares about this except you and I...

  28. Zash

    Could it not rather be that nobody cares about this _right now_?

  29. Ge0rG

    I think we are already deep in the hole of inconsistent content displays with XHTML-IM and LMC, so we are not making the mess any worse.

  30. dwd

    Zash, Yes, indeed. But nobody cared when 428 was published either.

  31. larma

    Do you expect people to answer on the mailing list "I'm on daves side", without any further points made?

  32. Ge0rG

    Can we make it a popularity contest?

  33. Zash

    Inb4 someone brings up switching to a discussion platform with a šŸ‘ļø button

  34. Ge0rG

    Zash: We all know that you have simple buttons.

  35. larma

    Zash, sounds like we just need more clients to implement XEP-444 šŸ™‚

  36. dwd

    larma, Well, I don't view it as sides, but the idea is to design protocols such that we as a community have rough consensus we're doing it right. Very hard to judge that if nobody says anything.

  37. larma

    dwd, 100% agree

  38. Zash

    Is assumption of silence equaling agreement less than optimal?

  39. dwd

    Zash, When there's two conflicting suggestions on the table, then which is the silence assenting to?

  40. larma

    FWIW, I honestly think that if the fallback+reply-to xep was accepted as is, it will be implemented by some clients. Whereas a reply-to without sensible fallback probably won't. And reply-to is a commonly requested feature

  41. Kev

    > Do you expect people to answer on the mailing list "I'm on daves side", without any further points made? I tend not to do this, as long as the points I would make have been made.

  42. Ge0rG

    Kev: how is council going to evaluate which points are more convincing?

  43. dwd

    larma, I think clients are already doing a reply without any metadata at all, just the markup/down.

  44. larma

    Kev, yeah that works great if one can rationally conclude from the points made which is the best option, which seems to not be the case here, thus the problem.

  45. larma

    dwd, exactly, but also nobody really likes that, it's just the best we have because we (the people doing the specifications) don't move forward on this and related discussions šŸ˜•

  46. Kev

    > Kev: how is council going to evaluate which points are more convincing? I don't think decisions should be made based on who is most vocal on the lists.

  47. Kev

    But where Council would like to judge such a thing, I think asking where people fall is not stupid.

  48. Ge0rG

    For the record: I think the UX improvements created by replies and body fallback erasure are worth the additional attack surface.

  49. Ge0rG

    However, I still slightly tend to reject on formal grounds.

  50. Kev

    > Kev, yeah that works great if one can rationally conclude ... Quite. And I'm afraid I've been off work for the best part of a month until this week, so haven't been monitoring XSF stuff (and pretty much archived it all when I got back). Not that I'm suggesting it's my opinion you're seeking, but if there are threads that want more discussion, maybe they could be bumped with context for why more discussion is desired?

  51. Ge0rG

    Fallbacks because I really see it as part of 0428, and replies because we still haven't figured out message fastening

  52. dwd

    larma, Could you simplify the body editing to cover the reply case explicitly, rather than making it quite so generic?

  53. Ge0rG

    dwd: what's the problem with it being generic? You reverse sort the fallback elements by offset, then remove all the supported ones in one pass

  54. Ge0rG

    I'm sure we can also make use of fallbacks for SIMS / OOB files

  55. dwd

    Ge0rG, I think most fallback cases are all-or-nothing. I don't think we want to worry about markdown fallback. Replies I see the benefit, but with a generic pre-display editing capability I just think that's a lot of attack surface for the desired outcome.

  56. larma

    dwd, I could, but it's really complicated. There is no standard markup for the reply fallback and you need flexibility for internationalization purposes.

  57. Ge0rG

    Maybe it's even not generic enough, in case some XEP provides different elements under the same namespace that warrant a fallback.

  58. dwd

    larma, Strip leading characters only?

  59. Ge0rG

    dwd: the only alternative I see is to embed the fallback body into the fallback element, but that would refute most of the fallback purpose

  60. dwd

    Ge0rG, Yes, I circled around that thought too.

  61. larma

    Ge0rG, the string in `for` doesn't strictly need to be the namespace of the element, it can also be `$namespace:$elementname` for example ✎

  62. dwd

    larma, If you want that, you need two attributes.

  63. larma

    Ge0rG, the string in `for` doesn't strictly need to be the namespace of the element, it can also be `$namespace:$elementname` for example, in cases where namespace alone is not enough ✏

  64. Ge0rG

    dwd: could you come up with a convincing attack scenario, where actual message content gets manipulated in an unexpected way in one but not the other implementation?

  65. dwd

    larma, You can't concatenate a namespace and a local name into a single string.

  66. dwd

    Ge0rG, Yeah, I came up with a couple on the list.

  67. Ge0rG

    dwd: back in the 0428 days?

  68. dwd

    Ge0rG, No, in the last thread.

  69. Ge0rG

    Alright, will reread.

  70. larma

    dwd, citing from the ProtoXEP: "The <fallback> element has a 'for' attribute with an identifier of the specification the fallback is for. [...] The exact behavior for a compatibility fallback should be defined in the respective specification." aka. it doesn't say it must be the namespace, it can be literally anything right now.

  71. dwd

    Ge0rG, Reply fallbacks, for instance, allow you to not only strip the reply, but edit the message you're sending.

  72. dwd

    larma, Right, yes, you can have arbitrary identifiers there. But you can't just have $namespace:$element.

  73. Ge0rG

    dwd: edit the embedded fallback quote?

  74. dwd

    Ge0rG, Yes, but also the message you're sending in reply.

  75. Ge0rG

    dwd: LMC does so as well

  76. larma

    dwd, what I meant is, the specification for $element in $namespace can just declare that $namespace:$element is what should be in `for` attribute. It doesn't work in the generic case, but it does when specified like this.

  77. Ge0rG

    Yeah, so `for` must be the namespace or start with the namespace

  78. dwd

    Ge0rG, LMC replaces messages, so the entire message before and after edits is always obvious. This means that if you have content-based spam filtering, that would be unaffected.

  79. Ge0rG

    dwd: and XHTML-IM allows to send two conflicting messages

  80. dwd

    Ge0rG, Yes indeed, and I (and others) warned about that a few summits back.

  81. Ge0rG

    dwd: the only solution I can see for cases with audit trail requirements is to store the full original xml

  82. dwd

    But we also need to try every combination of fallback editing in order to figure out what the outcome might be.

  83. Ge0rG

    dwd: who is "we" in that scenario?

  84. larma

    dwd, would it make you happy if in the reply-to xep we state that the fallback as specified via the fallback xep should only be removed if it is a single continuous character sequence starting before the first character of the body and ending after a newline character?

  85. larma

    That would make abuse harder but still give enough flexibility ✎

  86. larma

    That would make abuse harder but still give enough flexibility for practical use ✏

  87. dwd

    larma, So removal of a prefix only?

  88. dwd

    larma, That would be fine by me. There is still an attack surface but much much smaller.

  89. larma

    exactly, but still use the fallback xep so that non-supporting clients still now it's a fallback (without removing it) ✎

  90. larma

    exactly, but still use the fallback xep so that non-supporting clients still now it's a fallback (without removing it, they can still dim it or whatever in this case) ✏

  91. Ge0rG

    But that limits fallback to one element per message, right?

  92. dwd

    Ge0rG, For now. Operational experience may suggest we need to expand it.

  93. larma

    Ge0rG, no, that's a rule specific for reply-to (and will be in reply-to XEP), other XEPs may have different rules.

  94. Ge0rG

    What if I want to reply-to to multiple messages?

  95. dwd

    larma, Why not just start with only supporting prefix removal? It is the only compelling case we have right now. I'd be concerned that rule would simply be ignored.

  96. larma

    Thinking of, for example, message markup (the one that is not styling aka markdown) could declare that only single characters that would trigger a message styling start or end can be removed, etc

  97. dwd

    larma, That's unenforceable by definition.

  98. Ge0rG

    dwd: what about replying-to a message with an inline file indicated by OOB?

  99. Ge0rG

    OOB would remove postfixes of the message, reply-to prefixes

  100. larma

    Ge0rG, that's out of scope for this XEP (the solution: send two messages) ✎

  101. larma

    Ge0rG, that (reply to two messages) is out of scope for this XEP (the solution: send two messages) ✏

  102. Ge0rG

    larma: well, reypl-to-two was the first synthetic corner case example I was able to come up with

  103. larma

    (this is what I see in most other messengers, I don't know any that supports replying to two messages in one)

  104. larma

    dwd, I disagree that it's unenforcable by definition. Message styling has clear rules when characters can trigger styling. Message markup can refer to those rules.

  105. dwd

    larma, Sure, but to support that on the receiving end you'd need to understand the rules you don't implement.

  106. larma

    dwd, you are assuming that I don't implement this rules

  107. dwd

    larma, Yes, because if you do you know what characters are markup.

  108. Ge0rG

    my point is: if we define the fallback semantics as "strip the first N body characters for the <namespace> element", and we end up with multiple fallback elements inside the stanza, we still have selective removal of body parts if a receiving client implements the fallback #2 but not fallback #1 namespace

  109. Ge0rG

    dwd: you only strip the fallback if you know the rules.

  110. larma

    dwd, markup and styling don't have exactly the same feature set, so it makes sense to support both at the same time and still declare styling as a fallback.

  111. dwd

    Ge0rG, Yes, but if you know what characters are and are not markup, in order to know whether the rules are legal, then you *also* know which characters to strip anyway, right?

  112. larma

    dwd, styling does not strip characters

  113. larma

    > It is RECOMMENDED that styling directives be displayed and formatted in the same manner as the text they apply to. For example, the string "*emphasis*" would be rendered as "*emphasis*".

  114. larma

    (the bold got loss because I couldn't use message markup to make it bold :D) ✎

  115. larma

    (the bold got lost because I couldn't use message markup to make it bold :D) ✏

  116. larma

    (the bold in the second example string got lost because I couldn't use message markup to make it bold :D) ✏

  117. larma

    in case it's unclear why this is needed: You might trigger those styling directive accidentally when typing formulars etc, so stripping them will render those messages unreadable

  118. Ge0rG

    Trying to solve a security issue by adding complexity is a huge red flag.

  119. dwd

    larma, OK, so we're talking a client that supports XEP-0393, and therefore knows which characters form a "styling directive", but you're using a fallback directive for an identifier it understands to remove those, to cover the case where a user naively types characters such that they do form a span but that span is unintentional, from a client that also does understand XEP-0393?

  120. Ge0rG

    So I'm still torn somewhere between "only allow a prefix of the message to be stripped", "allow each fallback element to iteratively strip a prefix of the (remaining) message, as long as you support all preceding fallbacks" and "let each fallback strip whatever it wants"

  121. dwd

    larma, I'm going to go with "niche".

  122. larma

    dwd, maybe my example was a bit to unclear. Let's say I want to write "This is important" and make the important bold. With message markup (0394) I can just make the important bold and that's it. With Message styling (0393) I need to add styling directives (asterisks) into my body, but that's still better to not make it bold. So I will send "This is *important*" to have a fallback for legacy clients and trigger message styling. But then I also add 0394 markup for the word important and add a fallback element that says that the two asterisks are fallback, so I client supporting 0394 will not display the asterisks but still make it bold - which is what I wanted in first place. ✎

  123. larma

    dwd, maybe my example was a bit to unclear. Let's say I want to write "This is important" and make the "important" bold. With message markup (0394) I can just make the important bold and that's it. With Message styling (0393) I need to add styling directives (asterisks) into my body, but that's still better to not make it bold. So I will send "This is *important*" to have a fallback for legacy clients and trigger message styling. But then I also add 0394 markup for the word important and add a fallback element that says that the two asterisks are fallback, so I client supporting 0394 will not display the asterisks but still make it bold - which is what I wanted in first place. ✏

  124. larma

    dwd, maybe my example was a bit to unclear. Let's say I want to write "This is important" and make the "important" bold. With message markup (0394) I can just make the important bold and that's it. With Message styling (0393) I need to add styling directives (asterisks) into my body, but that's still better to not make it bold. So I will send "This is *important*" to have a fallback for legacy clients and trigger message styling. But then I also add 0394 markup for the word important and add a fallback element that says that the two asterisks are fallback, so a client supporting 0394 will not display the asterisks but still make it bold - which is what I wanted in first place. ✏

  125. dwd

    OK, so the receiving client supports 394 only, and cannot tell if the fallback editing for the lack of 393 is legitimate or not?

  126. daniel

    fwiw i have 393 in it's current form (w/o fallback or ignore tags or anything) deployed to ~6 million users and from all the complaints i get daily from users not one has ever complained about the formatting

  127. larma

    If a receiving client does not support 393 and don't want to implement its rules to check if the fallback can be removed, they can either decide to remove it no matter what (risking abuse), make simplified rules (e.g. only single characters can be removed, still risking abuse but making it less likely) or just not remove (which is still better than nothing). Most clients though will support 393 and/or implement its rules in the near future, so I don't think it's a big deal.

  128. larma

    daniel, FWIW, you are a mobile client and I hardly know any mobile client that supports proper rich text (and not just markdownish), because how would you Ctrl-B to make text bold without a keyboard šŸ˜€

  129. larma

    Also, nothing is wrong with moving the markdownish logic into the sending client and send using 0394-like markup only on wire.

  130. Zash

    Less than nothing wrong, it'd be pretty good.

  131. larma

    Zash, yeah, that's kinda my longterm goal, but it's a long way to get there.

  132. larma

    and without some fallback mechanism, transition is gonna be hard...

  133. Zash

    Server-side xhtml-im? šŸ˜€

  134. larma

    server-side e2e message decryption?

  135. Zash

    mod_omemo you say?

  136. Zash

    for meeeeeee, the self-hosted on a single user server, that'd be pretty great

  137. larma

    I guess we're kinda getting off-topic here. Point is, fallback for 0394-like message markup is part of design considerations in my fallback proto xep (it even is in the second example) and a restriction to prefix-only would make that usecase impossible.

  138. larma

    If we reach consensus that what I proposed in the proto xep should be part of 0428 instead, I certainly can prepare a PR to rewrite 90% of 0428 - it still feels weird to me to bluntly modify the original meaning of that XEP but I can deal with it (and afaik nobody implemented 0428 as it is right now, so apparently it wasn't very useful anyway)

  139. Zash

    Feature creep indeed

  140. Ge0rG

    dwd: is larma's proposal okay with you?

  141. dwd

    Amusingly, I'm working on server-side e2ee decryption right now. And for improving security, too.

  142. dwd

    Ge0rG, I'd really appreciate a message to the list outlining it, so we can see what other people feel about it. I worry it's still more complex than I'd like, but it's movement in the right direction at least.

  143. dwd

    Ge0rG, But to be clear, my view is much less important than consensus.

  144. Ge0rG

    Unfortunately, I've been asleep for the last two weeks, so I have a pressing deadline to veto or not-veto the proto-XEP today.

  145. dwd

    Ge0rG, I *thought* we'd agreed that we should fold both proposals into '428?

  146. larma

    Ge0rG, you can always veto and if necessary we put it up for vote again

  147. Ge0rG

    But given the previous communications on list from you two, it looks like we can arrive at a 0428 containing a significant subset of the proto-XEP

  148. Ge0rG

    larma: right, but it's also a bad practice to just re-cast a vote without significantly changed circumstances.

  149. larma

    though I agree that it feels like we're going to merge everything into 0428

  150. larma

    Ge0rG, yeah, but "merging in 0428 did not work out" would be changed circumstances, no?

  151. Ge0rG

    So I'm going to veto Compatibility Fallbacks.

  152. Ge0rG

    larma: good point

  153. Ge0rG

    larma: I'm also _most probably_ going to veto call-invites, because it has _very significant_ overlap with 0353 and is missing a clear rationale what's different. If it is only about embedding a URI of an external conference system / phone number, then maybe we can find a way to stuff that URI into 0353 or into Jingle?

  154. Ge0rG

    And I've been thinking whether to also veto Replies because of a lack of rationale (how it differentiates from threads et al) and the message referencing mess that we are in, but the former was already suggested for later in the process and the latter is not the protoXEP authors' fault

  155. Ge0rG

    So I'm probably going to +0 Replies.

  156. larma

    call invites is mostly about: - not being about establishing a jingle connection but a call, which may include multiple participants (jingle connections are always between two entities) - extensibility and fallbacks for various connection methods What it's primarily intended for right now, is to initiate a Muji group call as described in https://github.com/xsf/xeps/pull/1139

  157. larma

    reply-to is referencing the fallbacks proto xep so I don't think it makes a lot of sense to accept it before the fallbacks update

  158. flow

    there has been some work on multi party jingle, like xep272, fwiw

  159. Ge0rG

    larma: I'm pretty sure that 0353 is also mostly about calls (at least 1:1) and not so much about file transfers, and it would be beneficial to see if you can do Muji over 0353 as well

  160. Ge0rG

    larma: the wire format of reply-to can be completely rewritten in experimental, I'm only concerned about assigning XEP numbers to duplicate functionality.

  161. daniel

    i think 353 makes a lot of sense for file transfer as well. if it weren't for my crappy jingle-ft implementation (that's completely independent of the newly written jingle rtp implementation) i'd happly use 353 for ft as well

  162. daniel

    That's not to say it couldn't also be used for muji

  163. larma

    I agree with daniel that it is kinda weird to remove a feature from a XEP that was there just because it isn't used in practice (yet) ✎

  164. larma

    I agree with daniel that would be kinda weird to remove a feature from a XEP that was there just because it isn't used in practice (yet) ✏

  165. Ge0rG

    I wasn't going to suggest removing FT from 0353

  166. dwd

    At this point, we're probably best off discussing somewhere else, but can't the Muji extensions fit within the <propose/> of the intent message in '353?

  167. larma

    Trying to merge 353 with FT and generic any-transport call invites seems a little bit weird to me

  168. Ge0rG

    larma: I haven't looked into the muji wire protocol, but what would be wrong about embedding it into 0353?

  169. larma

    dwd, right now those elements in there are jingle description. If you put an element there that is not a known jingle description to the recipient, they should not be able to accept the call. ✎

  170. larma

    dwd, right now those elements in <propose/> are jingle description elements. If you put an element there that is not a known jingle description to the recipient, they should not be able to accept the call. ✏

  171. daniel

    i donā€™t know enough about muji to make a call on whether or not it can be fit into 353. but i'm too (taking my council hat off here for a second) sceptical of the new proposed xep that ignores the existance of 353

  172. Ge0rG

    daniel: I'm with you here. I'm going to veto call-invites until it comes back with a water-tight rationale for why 0353 absolutely can't be used

  173. Ge0rG

    but my preferred outcome is actually merging muji calls into 0353

  174. larma

    FWIW, I tried to merge in 353 first, it just didn't work out

  175. Ge0rG

    because it really looks like it's reinventing all of the 353 wire protocol, with different names.

  176. Ge0rG

    I'd also be okay with a 353' protoXEP that re-uses 0353 wire protocol and defines a new child element for it

  177. dwd

    Ge0rG, I'd suggest working with Thilo, who seems very active in this space.

  178. larma

    (council hat off) as this is probably not going to work out before our next Dino release, we'll have to release out-of-spec behavior to get group calls live

  179. larma

    dwd, guess who I've talked to about this topic a lot already...

  180. daniel

    larma: can you put it into some weird Dino namespace that's not a even a valid uri?

  181. Zash

    no no noooooooo

  182. daniel

    And then have it become a widely deployed thing

  183. larma

    daniel, sure, would probably be what we're going to do, but I really don't like it

  184. dwd

    daniel, Please no.

  185. Zash yeets a bath tub in the general direction of daniel

  186. larma

    Another thing that I wanted to point out, is that call invites can even use 353 as a means to discover full jid (because that is not part of call invites as it doesn't work properly in MUCs due to this nick sharing thing) ✎

  187. larma

    Another thing that I wanted to point out, is that call invites can even use 353 as a means to discover full jid (because that is not part of call invites as it doesn't work properly in MUCs due to this multi session nick thing) ✏

  188. larma

    Also 353 with the latest changes moved even more towards 1:1 only because of the tie breaking which doesn't work outside 1:1 and wouldn't even work for call invites (because those can be invites to two different calls)

  189. larma

    Maybe another solution would be to restrict the proto xep explicitly to be not used for direct 1:1 calls?

  190. larma

    so there is no feature overlap anymore

  191. Ge0rG

    daniel: let me tell you a tale of app-specific namespaces. ``` count pep node 20969 pep_eu.siacs.conversations.axolotl.devicelist 879 pep_eu.siacs.xmpp_messenger.axolotl.devicelist 201 pep_com.KDJStudios.XMPPJabberClient.axolotl.devicelist 148 pep_eu.siacs.storizima.axolotl.devicelist 118 pep_com.yaari.storizim.axolotl.devicelist 107 pep_mob.titecs.cackle.axolotl.devicelist 15 pep_com.kwikchat.app.axolotl.devicelist 7 pep_de.nxmedia.app.android.c0nnect.axolotl.devicelist 5 pep_com.securedsoftware.vaultim.axolotl.devicelist 4 pep_com.a3india.conversations.axolotl.devicelist 3 pep_lu.pgd.conversations.axolotl.devicelist 3 pep_com.onionsearchengine.onionmessenger.axolotl.devicelist 3 pep_chat.conab.gov.br.axolotl.devicelist 2 pep_xyz.glidermessenger.glider.axolotl.devicelist 2 pep_de.tengu.chat.axolotl.devicelist ```

  192. daniel

    the most painfull thing about this is that people who fork Conversations clearly donā€™t know how to change the application id

  193. larma

    luckily, we don't have a ton of forks just to add ads and be free in the play store šŸ˜€

  194. jonasā€™

    what the holy backlog

  195. daniel

    Ge0rG, also this was very obviously (maybe not that obviously?) a joke on how not to repeat the mistakes omemo made

  196. daniel

    or I made to be more specific

  197. larma

    I really would prefer if we find a solution before the Dino release date, because that Dino version is going to be in Ubuntu LTS 22.04 and thus be around for at least 4 years, so we have to maintain backwards compatibility with it šŸ˜•

  198. Zash mumbles something annoyed about the 10 year extended support period

  199. Ge0rG

    larma: when is the dino release date?

  200. Zash

    something something oldoldstable

  201. vanitasvitae_

    Ge0rG: hehehe

  202. Zash

    larma, and remember to release without any security issues whatsoever, since they're not fixing those

  203. larma

    Ge0rG, Ubuntu imports from Debian testing before February 24, we are aiming early February to make sure it gets into Debian testing on time.

  204. larma

    FWIW, if we don't do a release, Ubuntu will package some random version from our git that is currently in testing šŸ˜•

  205. larma

    Zash, not entirely true: https://launchpad.net/ubuntu/+source/dino-im/0.0.git20180130-1ubuntu0.1

  206. Zash

    who did you have to bribe for that?

  207. larma

    It's important that you get CVEs, that's the only language understood by Ubuntu security team

  208. Ge0rG

    larma: I'm very sorry that I've been sitting on this for the last two weeks. In case you run into time constraints because I'm blocking on something, feel free to ping and pressure me into deciding sooner :)

  209. Zash

    My understanding is that their policy for software in 'universe' is "lol, do it yourself"

  210. jonasā€™

    oh no the markup wars are back

  211. Ge0rG

    larma: but I still think that having one XEP for 1:1 call initiation and a completely separate XEP for 1:N call initiation that's using completely different wire format is extremely unfortunate

  212. jonasā€™

    so I am roughly on daves side w.r.t. the removal of stuff

  213. larma

    jonasā€™ is still reading backlog šŸ˜€

  214. jonasā€™

    no, just back from that

  215. jonasā€™

    I won't have the time today to read through all of the discussion on list (again)

  216. jonasā€™

    I would like to point out that reusing wire format for calls is extremely valuable considering the push infrastructure required for stuff like iOS

  217. larma

    Ge0rG, I do somewhat agree, and I would say it's possible to merge those *if* we agree on getting rid of FT support in 353 and make a bunch of things in 353 optional, but giving that Thilo put so much effort into fleshing out 353 to work great for 1:1, I'm not sure how to proceed here ✎

  218. larma

    Ge0rG, I do somewhat agree, and I would say it's possible to merge those *if* we agree on getting rid of FT support in 353 and make a bunch of things in 353 optional, but given that Thilo put so much effort into fleshing out 353 to work great for 1:1, I'm not sure how to proceed here ✏

  219. jonasā€™

    so as mostly a bystander in the A/V debate I am quite unhappy that there was apparently no talk with fippo or the 353 maintainers

  220. jonasā€™

    larma: tried talking to thilo in the past two weeks?

  221. jonasā€™

    they said on list they would've liked to talk AIUI

  222. Ge0rG

    larma: why would you want to remove FT from 353?

  223. larma

    jonasā€™, yes, talking with Thilo about 353 rework since November

  224. jonasā€™

    they seemed surprised on list about the protoxep though

  225. jonasā€™

    or am I mixing something up?

  226. jonasā€™

    on mobile, cannot search

  227. larma

    I haven't mentioned to him that we're doing this as an alternative before we uploaded it AFAIK

  228. larma

    Ge0rG, I don't want to, but it really doesn't work to have a call invites (generic and independent of transport method) and Jingle File Transfers in the same XEP

  229. Zash

    Mmmmmulti-destination Jingle File Transfer?

  230. larma

    either we make the XEP about a transport method (Jingle) or about a content type (Calls)

  231. jonasā€™

    larma: that sounds right

  232. jonasā€™

    or something I could get behind on

  233. jonasā€™

    might be worth turning 353 around to focus on calls

  234. jonasā€™

    afk now

  235. larma

    Yes either 353 is changed to Calls only, with Jingle just one means of transport, or is kept as is (generic method for Jingle) and then we need a new generic thing for calls. I personally would prefer the XEP for calls and for Files (we already have SIMS/SFT for that) independent, but unfortunately 353 currently is for transport method, so this would shift its current feature set

  236. larma

    So, *if* we agree on changing 353 to be calls only (not FT) and independent of Jingle, I guess I will find a way to figure things out with Thilo to get this done on time for Dino ✎

  237. larma

    So, *if* we agree on changing 353 to be calls only (not FT or XML streams or any other Jingle content it currently supports) and independent of Jingle, I guess I will find a way to figure things out with Thilo to get this done on time for Dino ✏

  238. Ge0rG

    larma, daniel: are FT initiation semantics different from call initiation semantics?

  239. larma

    In Jingle or in other transport methods?

  240. Ge0rG

    in jingle

  241. larma

    The major difference I would see is that the intent is different. For Calls, you want to accept them on at most one device and you want to be able to cancel the ringing on all devices from just one device. For FT, you might want to receive the file on multiple devices and rejecting the file on one device does not rule out that you still want to retrieve it on another device

  242. larma

    So the semantics of JMI don't really fit the typical UX for file transfers I'd expect

  243. Kev

    (FWIW, ignoring technical issues, the flow for a user of files vs calls are completely different) ✎

  244. Kev

    (FWIW, ignoring technical issues, I agree that the flow for a user of files vs calls are completely different) ✏

  245. Kev

    (In fact, I'm not at all convinced that P2P one-off file transfer is the most useful thing for most people)

  246. daniel

    I think it depends. If you are thinking about inline media then yes. If you are thinking about capital F Files then jmi can be fine

  247. daniel

    Here is this Linux ISO image. What Client would you like to receive this on. Surely not all of them

  248. larma

    SIMS/SFT solve this by not actually starting a jingle file transfer, but telling the recipient where to fetch the file from (which can result in multiple independent Jingle FT) ✎

  249. Kev

    daniel: Sure, but that ISO is probably also not time-sensitive in the way that a call is.

  250. daniel

    No. But I still would like to have the offer on all my clients and then decide which device should receive it

  251. larma

    SIMS/SFS solve this by not actually starting a jingle file transfer, but telling the recipient where to fetch the file from (which can result in multiple independent Jingle FT) ✏

  252. larma

    daniel, which you can with SFS

  253. daniel

    i guess... but i kind like to keep a universal way to establish a jingle session w/o a specific resource. because jingle is universal and not just files and calls

  254. daniel

    if we take 353 away and only solve files and calls then we donā€™t have this anymore

  255. dwd

    So... Do we have/want a concept of a data channel, like WebRTC does, and if so, where would this fit in? Anywhere?

  256. jonasā€™

    generalism is often a fallacy

  257. larma

    daniel, well that was my thinking as well, but in the meantime, everyone told me that 353 is not really meant to be used for anything but calls šŸ˜•

  258. Kev

    > generalism is often a fallacy That seems over-general of you.

  259. jonasā€™

    we have the acute requirement of making call initiations immediately visible even on push-only devices, so having those easily recognizable for the server is crucial

  260. dwd

    jonasā€™, Well, too much generalism and you don't have anything concretely useful, yes. Too little, and you don't have anything generally useful.

  261. daniel

    larma: who is everyone

  262. larma

    dwd, webrtc data channels are a jingle transport method (the current XEP is broken, but nobody seems to care) ✎

  263. larma

    dwd, webrtc data channels are a jingle transport method (the current XEP is broken, but nobody seems to care) and thus is not relevant here ✏

  264. larma

    daniel, well, it seems to be a popular opinion

  265. larma

    Not going to name people šŸ˜€

  266. Ge0rG

    What have I initiated?

  267. dwd

    larma, I'm thinking less of the transport itself, and more the concept that two XMPP entities may wish to setup a binary p2p channel. WebRTC-land systems build p2p file transfer from this. I'm wondering if this concept would fit semantically into 353, or something else entirely.

  268. jonasā€™

    Ge0rG, also, why here, it would've been much better to have this in xsf@ for visibility.

  269. daniel

    Fwiw I would probably care. One of these days I would really like to fix my jingle ft implemention and support webrtc based file transfer (in addition to the current ones)

  270. dwd

    jonasā€™, We sort of started here and it's continued.

  271. Ge0rG

    jonasā€™: it all started out as "I need to decide what to veto today"

  272. daniel

    But I absolutely don't have the time and energy for that

  273. jonasā€™

    (maybe we should revisit the "merge council@ into xsf@" idea)

  274. daniel

    So it's not not caring

  275. Kev

    > (maybe we should revisit the "merge council@ into xsf@" idea) I'm still on 'please don't' for that :)

  276. jonasā€™

    sorry, you're not on council

  277. larma

    dwd, it works with SFS (XEP-0447) for as long as both sides support the corresponding transport method

  278. Ge0rG

    I like having this place for Council meetings and discussions, sorry for accidentally escalating general protocol discussions.

  279. larma

    maybe we should all just stop talking here and continue at xsf@, without giving any context there whatsoever? šŸ˜€

  280. Kev

    > sorry, you're not on council That's uncalled for.

  281. larma

    unless it's council meeting of course

  282. larma

    daniel, yes, I only know because I cared once but then lacked energy and time to fix it

  283. jonasā€™

    I mean the good thing is that people can read up on logs.xmpp.org, but IME trying to transfer a conversation from one place to another is quite lossy

  284. jonasā€™

    Kev, sorry, but I'm not sure why this matters for anyone except council

  285. Kev

    It matters *most* for people who aren't Council.

  286. Kev

    Having council meetings in council@ means that anyone who wants to observe Council needs to only watch for council@ to pop up with activity in their roster to know Council are active.

  287. Sam

    ^

  288. Sam

    Or +1 or whatever annoying notification we're generating these days.

  289. Kev

    AOL

  290. jonasā€™

    Kev, right, that makes sense

  291. moparisthebest

    almost that time

  292. Ge0rG

    moparisthebest: you are waaaaay too early

  293. Ge0rG triggers NTP resync, just in case

  294. moparisthebest

    my opinion on the whole jingle thing is roughly in a contest between "it might be nice if..." vs "running code" the "running code" should always win, ie, accept the protoxep

  295. jonasā€™

    moparisthebest, normally I'd agree

  296. jonasā€™

    however! the running code is, AFAIK, not taking mobile and the push challenges into account

  297. jonasā€™

    where building upon the '353 payload would be preferable

  298. moparisthebest

    Ge0rG, 6 minutes from now no ?

  299. jonasā€™

    way too early!

  300. jonasā€™

    I propose we settle this debate in a round of hedgewars

  301. moparisthebest

    ah ok, you had me worried some DST thing happened :)

  302. moparisthebest

    my calendar alarm is what didn't go off 2 weeks ago, so I resorted to a standard alarm, but that doesn't take DST into account :'(

  303. moparisthebest

    I hate computers, or timezones, or both

  304. jonasā€™

    we typically discuss DST a week before it happens

  305. daniel

    It's time

  306. daniel

    1) Roll call

  307. moparisthebest

    o/

  308. jonasā€™ escapes out of hedgewars

  309. jonasā€™

    o/

  310. Ge0rG .o/

  311. larma

    šŸ‘‹ļø

  312. daniel

    2) Agenda Bashing

  313. daniel

    Ge0rG, wanted to propose an AOB. but since this effects pending votes (which comes before AOB) we should probably discuss now

  314. jonasā€™

    ack

  315. daniel

    if there is anything left to discuss after the earlier discussion

  316. Ge0rG

    I have a feeling that most of my AOB has been covered.

  317. jonasā€™

    I had to read the discussion in a tram on my way home, and I'm a bit dizzy now

  318. Ge0rG

    But yeah, I'd like to give a summary as a pre-pending-votes AOB block

  319. jonasā€™

    yes please

  320. daniel

    Ge0rG, go ahead then

  321. Ge0rG

    There was a set of three proto XEPs proposed two weeks ago, covering some ground that has already been proposed / implemented in other XEPs

  322. Ge0rG

    https://xmpp.org/extensions/inbox/replies.html is yet another mechanism to reference messages, in addition to references, fastening and what else we have.

  323. Ge0rG

    However, I think that it adds UX value and will probably play well with some sort of revised fallback, so I'm generally +1 on that, even though slightly hesitant because of the message-reference mess that we are in

  324. Ge0rG

    compatibility-fallback provides additional semantics to what we have in XEP-0428, while looking vaguely similar from the XEP title, and given that dwd agrees about merging the two and sorting out the exact security considerations on the way, I think it's better to reject this one.

  325. Ge0rG

    And call-invites is something that overlaps very much of 0353 and where it really wasn't made clear why it can't be achieved from 0353. The discussion that we have had in here about it made the points clear, and reinfoced my feeling that this should be merged into 0353 to focus on calls (1:1 and groups) and not have a dedicated wire protocol for the same UX semantics

  326. Ge0rG

    Thanks everybody for the productive discussion earlier today and for helping me make up my mind

  327. moparisthebest

    quite different UX was the takeaway I had

  328. Ge0rG

    moparisthebest: different UX between 0353 and call-invites?

  329. moparisthebest

    very different UX between "generic jingle(ie file sharing) invites" vs "call invites" yes

  330. daniel

    Ge0rG, I agree with your critism. However > Note well that no special criteria (other than acceptance by the Approving Body and minimal formatting compliance) need to be met in order for a XEP to be granted a status of Experimental. The granting of Experimental status must not be construed as indicating any level of approval by the XSF, the XMPP Council, or the XMPP developer community.

  331. jonasā€™

    moparisthebest, my take away was "in theory that, in practice '353 is mostly used for calls and in addition you wouldn't want to get push notifications for a file offer in contrast to a call on iOS (where those tend to be loud)"

  332. moparisthebest

    I'm not sure you wouldn't want a push notification for a file transfer you've been waiting for but that's starting to go down a rabbit hole...

  333. larma

    moparisthebest, at least you probably want to handle them differently

  334. jonasā€™

    moparisthebest, yes, though it makes sense to treat them differently still

  335. jonasā€™

    iOS is weird with call UI requirements for voice pushes

  336. moparisthebest

    to me, if the decision is "well we are going to need another XEP anyway, but maybe some things in this new one and 353 could be shuffled around" then accepting is the right thing to do

  337. jonasā€™

    right

  338. jonasā€™

    larma, what do you think here?

  339. jonasā€™

    daniel, do we want to extend the voting period by a week to give larma a chance to sync with thilo and primarily affected client devs about the options for '353?

  340. moparisthebest

    that sounds like a good idea to me...

  341. daniel

    sure.

  342. jonasā€™

    because I think the way forward depends on the agreement and commitment of a few parties anyway

  343. jonasā€™

    larma, do you think that'd be useful?

  344. jonasā€™

    I seem to recall that Ge0rG will be AFK next week though, which makes that a bit complex

  345. moparisthebest

    extend 2 weeks ?

  346. Zash

    if you're moving towards communicating semantics instead of transport methods, then that sounds awesome

  347. Ge0rG

    Three weeks.

  348. daniel

    reject and resubmit is virtually the same thing though, no?

  349. larma

    I think Jingle File Transfer are best done not using 0353 but 0447. AFAIK we can do three things over Jingle: Calls, File Transfer and XML streams. If we move 0353 to Calls only, we might need something like it for Jingle XML streams in the future, but nobody is doing those anyway.

  350. jonasā€™

    daniel, ack

  351. jonasā€™

    larma, ack

  352. Ge0rG

    I reject the current proposal anyway because it lacks a rationale that clearly describes how 0353 is unsuitable

  353. jonasā€™

    so whatever works is okay by meā€”I just would like that dino (who've been doing excellent work with conferencing) don't end up in a dead end here and I want that they have their work valued

  354. daniel

    ok. i'll ask for votes on the individual xeps in the "pending votes" section

  355. daniel

    should we move on then?

  356. jonasā€™

    wfm

  357. Ge0rG

    daniel: yes please

  358. daniel

    3) Editor updates

  359. daniel

    nothing new last week

  360. daniel

    4) Items for voting

  361. daniel

    XEP-0060: Specify pubsub#type to reflect semantic info (https://github.com/xsf/xeps/pull/1148) ✎

  362. jonasā€™

    +1

  363. daniel

    a) XEP-0060: Specify pubsub#type to reflect semantic info (https://github.com/xsf/xeps/pull/1148) ✏

  364. larma

    Ge0rG, for the record, I do think the Introduction of the proposal already has some decent words as to why 0353 is different

  365. moparisthebest

    +1

  366. Ge0rG

    That looks rather editorial to me, also +1

  367. daniel

    on list for that one

  368. larma

    daniel, +1 for me

  369. daniel

    Ok thank you

  370. daniel

    b) XEP-0256: Deprecate in favour of XEP-0319 (https://github.com/xsf/xeps/pull/1149)

  371. moparisthebest

    +1

  372. daniel

    As someone who implemented 319 and thought it was lacking stuff I'm not sure that 0319 "has won the race"

  373. Ge0rG

    +1

  374. jonasā€™

    +1

  375. jonasā€™

    what is it lacking?

  376. Ge0rG

    oh, I have an AOB for 319

  377. jonasā€™

    they look pretty identical to me

  378. Ge0rG

    Should it be put into CS'22?

  379. daniel

    i'm not saying it's better or worse than 256

  380. daniel

    but it didnā€™t feel ready

  381. jonasā€™

    apropos what happened to my agenda point about CS'22? :)

  382. jonasā€™

    it's draft tho

  383. daniel

    and it feels wrong to deprecate something in favor of something that isn't ready

  384. moparisthebest

    it looked like it just replaced relative time with absolute time to me ?

  385. daniel

    anyway i'm +0

  386. larma

    I think 319 lacks functionality to indicate that the timestamp is a rough estimate and not exact, but beside that, I'm +1 on getting rid of 256 so we don't have a duplicate

  387. moparisthebest

    that's basically always true of a timestamp you recieve from across the network, or, maybe from anywhere...

  388. jonasā€™

    daniel, Ge0rG is also already +1

  389. larma

    moparisthebest, no what I mean is, I set a timestamp that is rounded to the next full hour for privacy reasons, and I want to be able to tell that it's rounded

  390. larma

    (Telegram has that feature)

  391. daniel

    yes i have a bunch of issues with 319 but that's not the right forum for this and probably orthogonal to deprecating 256

  392. daniel

    anyway moving on

  393. daniel

    5) Pending votes

  394. moparisthebest

    actually that seems like it should be covered in security considerations, but yea going off on a tangent here...

  395. daniel

    Ge0rG, do you want to cast your votes on the three proto xeps now

  396. Ge0rG

    daniel: yes

  397. jonasā€™

    (four?)

  398. daniel

    four?

  399. daniel

    oh yes four

  400. jonasā€™

    at least the SoD doesn't havā€¦ ok :)

  401. Ge0rG

    https://xmpp.org/extensions/inbox/replies.html +0 I like the idea and the UX, but I dislike the mess we are in regarding message reference mechanisms

  402. Ge0rG

    https://xmpp.org/extensions/inbox/compatibility-fallback.html -1 This needs to be merged into 0428

  403. Ge0rG

    https://xmpp.org/extensions/inbox/call-invites.html -1 This should be merged into 0353 unless this merging fails, in which case it needs a better description of why 0353 is not sufficient. The one that it has I've read, but consider it inadequate as it lacks depth

  404. Ge0rG

    https://xmpp.org/extensions/inbox/pubsub-ns.html -1 As discussed before this needs to go into pubsub#type

  405. daniel

    ok thank you Ge0rG

  406. Ge0rG

    I'm not done yet

  407. jonasā€™

    I'm -1 on the '30 modification ✎

  408. Ge0rG

    #1145 removes too much from 0030, I've written my feedback to the ML. -1

  409. daniel

    i was about to call for votes on the 30 mod after that

  410. jonasā€™

    I'm -1 on the '30 modification, supporting the reasons on-list: It is well suited in the PEP add-ons. I like dwd's reasoning that "otherwise trusted" should be taken for that ✏

  411. daniel

    or now

  412. daniel

    because everyone is (or was) pending on that

  413. jonasā€™

    I'm -1 on the '30 modification, supporting the reasons on-list: It is well suited in the PEP add-ons. I like dwd's reasoning that "otherwise trusted" should be taken for that as an escape hatch. ✏

  414. moparisthebest

    also -1 on 30 mod, and I think the XEPs that make it useable for harvesting JIDs need fixed but again, tangent...

  415. jonasā€™

    moparisthebest, rationale for the -1?

  416. moparisthebest

    we shouldn't allow it to become useable for harvesting JIDs

  417. daniel

    i'm -1 too see my standards post

  418. moparisthebest

    I mean, it already is, and that needs fixed, not expanded

  419. jonasā€™

    moparisthebest, suggestions welcome I suppose (though that should go in xsf@)

  420. moparisthebest

    yep!

  421. daniel

    larma, do you want to vote now on the 30 mod?

  422. larma

    -1 here as well, similar reasoning as moparisthebest

  423. daniel

    ok

  424. larma

    I also don't think it's needed that you can disco to fetch the pep node šŸ¤·ļø

  425. daniel

    6) Date of Next

  426. Ge0rG

    +3W WFM

  427. jonasā€™

    +1w wfm

  428. jonasā€™

    happy holidays, Ge0rG

  429. daniel

    +1w wfm

  430. moparisthebest

    +1w wfm

  431. Ge0rG

    thanks very much

  432. larma

    +1w wfm

  433. daniel

    7) AOB

  434. daniel

    jonasā€™, had some but we are also over time.

  435. daniel

    are people fine by extending by 10mins ✎

  436. daniel

    are people fine by extending by 10mins? ✏

  437. jonasā€™

    ack

  438. Ge0rG

    +1

  439. larma

    fine with me

  440. daniel

    go ahead jonasā€™

  441. jonasā€™

    we should advance the CS-2022

  442. jonasā€™

    they're still stable and should be moved to final, now that '22 started

  443. jonasā€™

    or should we?

  444. jonasā€™

    anyway, if there are no objections, the editor may issue a CFE

  445. daniel

    have we moved previous CSes to final?

  446. daniel

    i actually can't remember

  447. jonasā€™

    we triedā€¦

  448. larma

    '21 is still Draft/Stable

  449. jonasā€™

    right

  450. jonasā€™

    we should definitely fix that

  451. jonasā€™

    I don't have strong opinions on the Final actually

  452. daniel

    we could try to move it to final. but i donā€™t think we have to necessarily

  453. jonasā€™

    given that it's now called stable, I can live with that

  454. daniel

    i think it provides value as is

  455. daniel

    plus how would apply the 2 implementations rule?

  456. daniel

    i donā€™t think there is even one which fully implements it

  457. jonasā€™

    right

  458. moparisthebest

    I feel like we should move it to final but I'm not going to cry about it either way :)

  459. Ge0rG

    I'm sure there is a bunch of implementations of Core Core XMPP.

  460. jonasā€™

    I'll prepare a PR for deprecation of the 2021 one

  461. jonasā€™

    End of AOB from my side

  462. Ge0rG

    I'm slightly in favor of moving '22 to final

  463. larma

    thanks jonasā€™

  464. larma

    is it deprecating or obsoleting '21?

  465. jonasā€™

    deprecation needs to come first anyway

  466. jonasā€™

    we can easily vote on both

  467. jonasā€™

    I mean we can right now, if we want

  468. jonasā€™

    which I'd like, given that Ge0rG is AFK for 2w

  469. daniel

    ok let's do this. we still have 5 minutes :-)

  470. jonasā€™

    I'm +1 on first deprecating and then obsoleting XEP-0443 (CS-2021)

  471. larma

    +1

  472. daniel

    (thank you for looking up the xep number :))

  473. daniel

    +1

  474. Ge0rG

    +1

  475. jonasā€™

    thank you for blindly believing me and unanimously obsoleting message styling

  476. jonasā€™

    ;)

  477. larma

    šŸ˜€

  478. Ge0rG

    jonasā€™: we still have Message Fancying

  479. jonasā€™

    moparisthebest, ^

  480. moparisthebest

    +1

  481. Zash

    Message Fancying is š¹š‘Žš‘›š‘š‘¦

  482. jonasā€™

    cool, so that's done

  483. daniel

    ok

  484. daniel

    8) Close

  485. daniel

    Thank you everyone

  486. jonasā€™

    thanks everyone, productive meeting (with the precursing discussion!)

  487. Ge0rG

    Thanks daniel

  488. moparisthebest

    thanks all :)

  489. Ge0rG

    Yeah, thanks very much for the discussion as well! :)

  490. moparisthebest

    have a good time Ge0rG !

  491. larma

    thanks šŸ™‚