XMPP Council - 2022-01-19


  1. neox has joined

  2. Kev has left

  3. Kev has joined

  4. pprrks has left

  5. pprrks has joined

  6. SouL has left

  7. _Liveware Problem_ has left

  8. pprrks has left

  9. pprrks has joined

  10. ChronosX88 has left

  11. ChronosX88 has joined

  12. debacle has left

  13. sonny has left

  14. sonny has joined

  15. pprrks has left

  16. Kev has left

  17. pprrks has joined

  18. Kev has joined

  19. pprrks has left

  20. pprrks has joined

  21. moparisthebest has left

  22. moparisthebest has joined

  23. pprrks has left

  24. pprrks has joined

  25. neox has left

  26. moparisthebest has left

  27. moparisthebest has joined

  28. pprrks has left

  29. pprrks has joined

  30. pprrks has left

  31. pprrks has joined

  32. pprrks has left

  33. pprrks has joined

  34. Kev has left

  35. Kev has joined

  36. pprrks has left

  37. pprrks has joined

  38. pprrks has left

  39. marc0s has left

  40. marc0s has joined

  41. msavoritias has joined

  42. msavoritias has left

  43. msavoritias has joined

  44. marc0s has left

  45. marc0s has joined

  46. me9 has joined

  47. Kev has left

  48. SouL has joined

  49. Kev has joined

  50. me9 has left

  51. SouL has left

  52. SouL has joined

  53. Kev has left

  54. Kev has joined

  55. _Liveware Problem_ has joined

  56. Kev has left

  57. Kev has joined

  58. sonny has left

  59. sonny has joined

  60. Tobias has joined

  61. Kev has left

  62. Kev has joined

  63. debacle has joined

  64. Kev has left

  65. Kev has joined

  66. neox has joined

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

  68. SouL has left

  69. SouL has joined

  70. msavoritias has left

  71. msavoritias has joined

  72. daniel

    ack

  73. daniel

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

  74. daniel

    Which might be my fault

  75. Ge0rG

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

  76. larma

    Ge0rG, we can also do now if it needs me 🙂

  77. Wojtek has joined

  78. Ge0rG

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

  79. Tobias has left

  80. Tobias has joined

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

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

  83. Zash

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

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

  85. Ge0rG

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

  86. Ge0rG

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

  87. Zash

    Ge0rG, +1 (wrt confusing names being ungood)

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

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

  90. Ge0rG

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

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

  92. Ge0rG

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

  93. larma

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

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

  95. larma

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

  96. Ge0rG

    Well, from a tactical point of view, I need to veto the XEP to ensure this discussion happens. 😉

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

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

  99. dwd

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

  100. dwd

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

  101. Zash

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

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

  103. dwd

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

  104. larma

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

  105. Ge0rG

    Can we make it a popularity contest?

  106. Zash

    Inb4 someone brings up switching to a discussion platform with a 👍️ button

  107. Ge0rG

    Zash: We all know that you have simple buttons.

  108. larma

    Zash, sounds like we just need more clients to implement XEP-444 🙂

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

  110. larma

    dwd, 100% agree

  111. Zash

    Is assumption of silence equaling agreement less than optimal?

  112. dwd

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

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

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

  115. Ge0rG

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

  116. dwd

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

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

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

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

  120. Kev

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

  121. Ge0rG

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

  122. Ge0rG

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

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

  124. Ge0rG

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

  125. dwd

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

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

  127. Ge0rG

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

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

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

  130. Ge0rG

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

  131. dwd

    larma, Strip leading characters only?

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

  133. dwd

    Ge0rG, Yes, I circled around that thought too.

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

  135. dwd

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

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

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

  138. dwd

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

  139. dwd

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

  140. Ge0rG

    dwd: back in the 0428 days?

  141. dwd

    Ge0rG, No, in the last thread.

  142. Ge0rG

    Alright, will reread.

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

  144. dwd

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

  145. dwd

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

  146. Ge0rG

    dwd: edit the embedded fallback quote?

  147. dwd

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

  148. Ge0rG

    dwd: LMC does so as well

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

  150. Ge0rG

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

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

  152. Ge0rG

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

  153. dwd

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

  154. Ge0rG

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

  155. dwd

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

  156. Ge0rG

    dwd: who is "we" in that scenario?

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

  158. larma

    That would make abuse harder but still give enough flexibility

  159. larma

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

  160. dwd

    larma, So removal of a prefix only?

  161. dwd

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

  162. larma

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

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

  164. Ge0rG

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

  165. dwd

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

  166. larma

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

  167. Ge0rG

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

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

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

  170. dwd

    larma, That's unenforceable by definition.

  171. Ge0rG

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

  172. Ge0rG

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

  173. larma

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

  174. larma

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

  175. Ge0rG

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

  176. larma

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

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

  178. dwd

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

  179. larma

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

  180. dwd

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

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

  182. Ge0rG

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

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

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

  185. larma

    dwd, styling does not strip characters

  186. 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*".

  187. larma

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

  188. larma

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

  189. larma

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

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

  191. Ge0rG

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

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

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

  194. dwd

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

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

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

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

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

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

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

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

  202. larma

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

  203. Zash

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

  204. larma

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

  205. larma

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

  206. Zash

    Server-side xhtml-im? 😀

  207. larma

    server-side e2e message decryption?

  208. Zash

    mod_omemo you say?

  209. Zash

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

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

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

  212. Zash

    Feature creep indeed

  213. ChronosX88 has left

  214. ChronosX88 has joined

  215. Tobias has left

  216. sonny has left

  217. sonny has joined

  218. sonny has left

  219. sonny has joined

  220. Ge0rG

    dwd: is larma's proposal okay with you?

  221. dwd

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

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

  223. dwd

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

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

  225. dwd

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

  226. larma

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

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

  228. Ge0rG

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

  229. larma

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

  230. larma

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

  231. Ge0rG

    So I'm going to veto Compatibility Fallbacks.

  232. Ge0rG

    larma: good point

  233. Tobias has joined

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

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

  236. Ge0rG

    So I'm probably going to +0 Replies.

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

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

  239. flow

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

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

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

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

  243. daniel

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

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

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

  246. Ge0rG

    I wasn't going to suggest removing FT from 0353

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

  248. larma

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

  249. Ge0rG

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

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

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

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

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

  254. Ge0rG

    but my preferred outcome is actually merging muji calls into 0353

  255. larma

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

  256. Ge0rG

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

  257. Ge0rG

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

  258. dwd

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

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

  260. larma

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

  261. daniel

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

  262. Zash

    no no noooooooo

  263. daniel

    And then have it become a widely deployed thing

  264. larma

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

  265. dwd

    daniel, Please no.

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

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

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

  269. Ge0rG has left

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

  271. larma

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

  272. larma

    so there is no feature overlap anymore

  273. Ge0rG has joined

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

  275. daniel

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

  276. larma

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

  277. jonas’

    what the holy backlog

  278. daniel

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

  279. daniel

    or I made to be more specific

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

  281. moparisthebest has left

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

  283. Ge0rG

    larma: when is the dino release date?

  284. Zash

    something something oldoldstable

  285. vanitasvitae_

    Ge0rG: hehehe

  286. Zash

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

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

  288. larma

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

  289. larma

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

  290. Zash

    who did you have to bribe for that?

  291. larma

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

  292. 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 :)

  293. Zash

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

  294. Tobias has left

  295. jonas’

    oh no the markup wars are back

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

  297. jonas’

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

  298. larma

    jonas’ is still reading backlog 😀

  299. jonas’

    no, just back from that

  300. jonas’

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

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

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

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

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

  305. jonas’

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

  306. jonas’

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

  307. Ge0rG

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

  308. larma

    jonas’, yes, talking with Thilo about 353 rework since November

  309. jonas’

    they seemed surprised on list about the protoxep though

  310. jonas’

    or am I mixing something up?

  311. jonas’

    on mobile, cannot search

  312. larma

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

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

  314. Zash

    Mmmmmulti-destination Jingle File Transfer?

  315. larma

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

  316. jonas’

    larma: that sounds right

  317. jonas’

    or something I could get behind on

  318. jonas’

    might be worth turning 353 around to focus on calls

  319. jonas’

    afk now

  320. Wojtek has left

  321. Tobias has joined

  322. Wojtek has joined

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

  324. moparisthebest has joined

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

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

  327. _Liveware Problem_ has left

  328. Ge0rG

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

  329. larma

    In Jingle or in other transport methods?

  330. Ge0rG

    in jingle

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

  332. larma

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

  333. Kev

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

  334. Kev

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

  335. Kev

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

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

  337. daniel

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

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

  339. Kev

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

  340. _Liveware Problem_ has joined

  341. daniel

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

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

  343. larma

    daniel, which you can with SFS

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

  345. daniel

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

  346. dwd

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

  347. jonas’

    generalism is often a fallacy

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

  349. Kev

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

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

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

  352. daniel

    larma: who is everyone

  353. larma

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

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

  355. larma

    daniel, well, it seems to be a popular opinion

  356. larma

    Not going to name people 😀

  357. Ge0rG

    What have I initiated?

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

  359. jonas’

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

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

  361. dwd

    jonas’, We sort of started here and it's continued.

  362. Ge0rG

    jonas’: it all started out as "I need to decide what to veto today"

  363. daniel

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

  364. jonas’

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

  365. daniel

    So it's not not caring

  366. Kev

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

  367. jonas’

    sorry, you're not on council

  368. larma

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

  369. Ge0rG

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

  370. larma

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

  371. Kev

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

  372. larma

    unless it's council meeting of course

  373. larma

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

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

  375. jonas’

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

  376. Kev

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

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

  378. Sam

    ^

  379. Sam

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

  380. Kev

    AOL

  381. jonas’

    Kev, right, that makes sense

  382. _Liveware Problem_ has left

  383. pprrks has joined

  384. pprrks has left

  385. pprrks has joined

  386. SouL has left

  387. vaulor has left

  388. vaulor has joined

  389. SouL has joined

  390. pprrks has left

  391. _Liveware Problem_ has joined

  392. pprrks has joined

  393. pprrks has left

  394. pprrks has joined

  395. Wojtek has left

  396. Wojtek has joined

  397. Tobias has left

  398. sonny has left

  399. sonny has joined

  400. Tobias has joined

  401. moparisthebest

    almost that time

  402. Ge0rG

    moparisthebest: you are waaaaay too early

  403. Ge0rG triggers NTP resync, just in case

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

  405. jonas’

    moparisthebest, normally I'd agree

  406. jonas’

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

  407. jonas’

    where building upon the '353 payload would be preferable

  408. moparisthebest

    Ge0rG, 6 minutes from now no ?

  409. jonas’

    way too early!

  410. jonas’

    I propose we settle this debate in a round of hedgewars

  411. moparisthebest

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

  412. 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 :'(

  413. moparisthebest

    I hate computers, or timezones, or both

  414. jonas’

    we typically discuss DST a week before it happens

  415. daniel

    It's time

  416. daniel

    1) Roll call

  417. moparisthebest

    o/

  418. jonas’ escapes out of hedgewars

  419. jonas’

    o/

  420. Ge0rG .o/

  421. larma

    👋️

  422. daniel

    2) Agenda Bashing

  423. daniel

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

  424. jonas’

    ack

  425. daniel

    if there is anything left to discuss after the earlier discussion

  426. Ge0rG

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

  427. jonas’

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

  428. Ge0rG

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

  429. jonas’

    yes please

  430. daniel

    Ge0rG, go ahead then

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

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

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

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

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

  436. Ge0rG

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

  437. moparisthebest

    quite different UX was the takeaway I had

  438. Ge0rG

    moparisthebest: different UX between 0353 and call-invites?

  439. moparisthebest

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

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

  441. 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)"

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

  443. larma

    moparisthebest, at least you probably want to handle them differently

  444. jonas’

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

  445. jonas’

    iOS is weird with call UI requirements for voice pushes

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

  447. jonas’

    right

  448. marc0s has left

  449. marc0s has joined

  450. jonas’

    larma, what do you think here?

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

  452. moparisthebest

    that sounds like a good idea to me...

  453. daniel

    sure.

  454. jonas’

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

  455. jonas’

    larma, do you think that'd be useful?

  456. jonas’

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

  457. moparisthebest

    extend 2 weeks ?

  458. Zash

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

  459. Ge0rG

    Three weeks.

  460. daniel

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

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

  462. jonas’

    daniel, ack

  463. jonas’

    larma, ack

  464. Ge0rG

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

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

  466. daniel

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

  467. daniel

    should we move on then?

  468. jonas’

    wfm

  469. Ge0rG

    daniel: yes please

  470. daniel

    3) Editor updates

  471. daniel

    nothing new last week

  472. daniel

    4) Items for voting

  473. daniel

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

  474. jonas’

    +1

  475. daniel

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

  476. larma

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

  477. moparisthebest

    +1

  478. Ge0rG

    That looks rather editorial to me, also +1

  479. daniel

    on list for that one

  480. larma

    daniel, +1 for me

  481. daniel

    Ok thank you

  482. daniel

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

  483. moparisthebest

    +1

  484. daniel

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

  485. Ge0rG

    +1

  486. jonas’

    +1

  487. _Liveware Problem_ has left

  488. jonas’

    what is it lacking?

  489. Ge0rG

    oh, I have an AOB for 319

  490. jonas’

    they look pretty identical to me

  491. Ge0rG

    Should it be put into CS'22?

  492. daniel

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

  493. daniel

    but it didn’t feel ready

  494. jonas’

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

  495. jonas’

    it's draft tho

  496. daniel

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

  497. moparisthebest

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

  498. daniel

    anyway i'm +0

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

  500. moparisthebest

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

  501. jonas’

    daniel, Ge0rG is also already +1

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

  503. larma

    (Telegram has that feature)

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

  505. daniel

    anyway moving on

  506. daniel

    5) Pending votes

  507. moparisthebest

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

  508. _Liveware Problem_ has joined

  509. daniel

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

  510. Ge0rG

    daniel: yes

  511. jonas’

    (four?)

  512. daniel

    four?

  513. daniel

    oh yes four

  514. jonas’

    at least the SoD doesn't hav… ok :)

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

  516. Ge0rG

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

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

  518. pprrks has left

  519. Ge0rG

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

  520. daniel

    ok thank you Ge0rG

  521. Ge0rG

    I'm not done yet

  522. jonas’

    I'm -1 on the '30 modification

  523. Ge0rG

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

  524. daniel

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

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

  526. daniel

    or now

  527. daniel

    because everyone is (or was) pending on that

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

  529. moparisthebest

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

  530. jonas’

    moparisthebest, rationale for the -1?

  531. moparisthebest

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

  532. daniel

    i'm -1 too see my standards post

  533. moparisthebest

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

  534. jonas’

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

  535. moparisthebest

    yep!

  536. daniel

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

  537. larma

    -1 here as well, similar reasoning as moparisthebest

  538. daniel

    ok

  539. larma

    I also don't think it's needed that you can disco to fetch the pep node 🤷️

  540. daniel

    6) Date of Next

  541. Ge0rG

    +3W WFM

  542. jonas’

    +1w wfm

  543. jonas’

    happy holidays, Ge0rG

  544. daniel

    +1w wfm

  545. moparisthebest

    +1w wfm

  546. Ge0rG

    thanks very much

  547. larma

    +1w wfm

  548. daniel

    7) AOB

  549. daniel

    jonas’, had some but we are also over time.

  550. daniel

    are people fine by extending by 10mins

  551. daniel

    are people fine by extending by 10mins?

  552. jonas’

    ack

  553. Ge0rG

    +1

  554. larma

    fine with me

  555. daniel

    go ahead jonas’

  556. jonas’

    we should advance the CS-2022

  557. jonas’

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

  558. jonas’

    or should we?

  559. jonas’

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

  560. daniel

    have we moved previous CSes to final?

  561. daniel

    i actually can't remember

  562. jonas’

    we tried…

  563. larma

    '21 is still Draft/Stable

  564. jonas’

    right

  565. jonas’

    we should definitely fix that

  566. jonas’

    I don't have strong opinions on the Final actually

  567. daniel

    we could try to move it to final. but i don’t think we have to necessarily

  568. jonas’

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

  569. daniel

    i think it provides value as is

  570. daniel

    plus how would apply the 2 implementations rule?

  571. daniel

    i don’t think there is even one which fully implements it

  572. jonas’

    right

  573. moparisthebest

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

  574. Ge0rG

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

  575. jonas’

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

  576. jonas’

    End of AOB from my side

  577. Ge0rG

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

  578. larma

    thanks jonas’

  579. Tobias has left

  580. larma

    is it deprecating or obsoleting '21?

  581. jonas’

    deprecation needs to come first anyway

  582. jonas’

    we can easily vote on both

  583. jonas’

    I mean we can right now, if we want

  584. jonas’

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

  585. daniel

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

  586. jonas’

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

  587. larma

    +1

  588. daniel

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

  589. daniel

    +1

  590. Ge0rG

    +1

  591. jonas’

    thank you for blindly believing me and unanimously obsoleting message styling

  592. Tobias has joined

  593. jonas’

    ;)

  594. larma

    😀

  595. Ge0rG

    jonas’: we still have Message Fancying

  596. jonas’

    moparisthebest, ^

  597. moparisthebest

    +1

  598. Zash

    Message Fancying is 𝐹𝑎𝑛𝑐𝑦

  599. jonas’

    cool, so that's done

  600. daniel

    ok

  601. daniel

    8) Close

  602. daniel

    Thank you everyone

  603. jonas’

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

  604. Ge0rG

    Thanks daniel

  605. moparisthebest

    thanks all :)

  606. Ge0rG

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

  607. moparisthebest

    have a good time Ge0rG !

  608. larma

    thanks 🙂

  609. _Liveware Problem_ has left

  610. Tobias has left

  611. daniel has left

  612. daniel has joined

  613. Tobias has joined

  614. mdosch has left

  615. mdosch has joined

  616. pprrks has joined

  617. pprrks has left

  618. pprrks has joined

  619. David has left

  620. David has joined

  621. sonny has left

  622. sonny has joined

  623. pprrks has left

  624. pprrks has joined

  625. Kev has left

  626. pprrks has left

  627. pprrks has joined

  628. Kev has joined

  629. Kev has left

  630. Kev has joined

  631. pprrks has left

  632. pprrks has joined

  633. Kev has left

  634. Kev has joined

  635. Wojtek has left

  636. Wojtek has joined

  637. Kev has left

  638. Kev has joined

  639. pprrks has left

  640. pprrks has joined

  641. pprrks has left

  642. pprrks has joined

  643. pprrks has left

  644. pprrks has joined

  645. pprrks has left

  646. pprrks has joined

  647. pprrks has left

  648. pprrks has joined

  649. pprrks has left

  650. pprrks has joined

  651. pprrks has left

  652. pprrks has joined

  653. pprrks has left

  654. pprrks has joined

  655. pprrks has left

  656. pprrks has joined

  657. Wojtek has left

  658. pprrks has left

  659. pprrks has joined

  660. pprrks has left

  661. pprrks has joined

  662. pprrks has left

  663. pprrks has joined

  664. pprrks has left

  665. pprrks has joined

  666. Kev has left

  667. Kev has joined

  668. sonny has left

  669. sonny has joined

  670. pprrks has left

  671. pprrks has joined

  672. Kev has left

  673. msavoritias has left

  674. neox has left

  675. Kev has joined

  676. sonny has left

  677. sonny has joined

  678. pprrks has left

  679. pprrks has joined

  680. Sam has left

  681. Sam has joined

  682. pprrks has left

  683. pprrks has joined

  684. _Liveware Problem_ has joined

  685. pprrks has left

  686. pprrks has joined

  687. pprrks has left

  688. pprrks has joined

  689. _Liveware Problem_ has left

  690. _Liveware Problem_ has joined

  691. Kev has left

  692. Kev has joined

  693. pprrks has left

  694. pprrks has joined

  695. pprrks has left

  696. pprrks has joined

  697. SouL has left

  698. pprrks has left

  699. pprrks has joined

  700. sonny has left

  701. sonny has joined

  702. pprrks has left

  703. pprrks has joined

  704. pprrks has left

  705. pprrks has joined

  706. pprrks has left

  707. pprrks has joined

  708. marc0s has left

  709. marc0s has joined

  710. pprrks has left

  711. pprrks has joined

  712. pprrks has left

  713. pprrks has joined

  714. ChronosX88 has left

  715. ChronosX88 has joined

  716. _Liveware Problem_ has left

  717. _Liveware Problem_ has joined

  718. ChronosX88 has left

  719. ChronosX88 has joined

  720. pprrks has left

  721. pprrks has joined

  722. pprrks has left

  723. pprrks has joined

  724. pprrks has left

  725. pprrks has joined

  726. pprrks has left

  727. sonny has left

  728. sonny has joined

  729. pprrks has joined

  730. sonny has left

  731. sonny has joined

  732. pprrks has left

  733. pprrks has joined

  734. pprrks has left

  735. pprrks has joined

  736. pprrks has left

  737. pprrks has joined

  738. pprrks has left

  739. pprrks has joined