XMPP Council - 2023-12-18


  1. Kev

    *bold* /italic/ _underline_ - other variations are insane :)

  2. singpolyma

    Kev: too bad we standardized a different one

  3. Kev

    Glad you agree :)

  4. singpolyma

    though no reason a client can't allow you to type that and then change it for on the wire

  5. theTedd

    It stems from viewing the markup as representing semantics, rather than direct styling. Emphasis is usually indicated with italics, and strong emphasis with bold - neither strictly means those styles and could be represented in any way appropriate for the medium. So any single pair of markers could indicate (weak) emphasis and doubling them produces double the emphasis (strong emphasis). [Tripling them should increase the font size; ten should fill your screen with a scrolling flashing banner.] Underline is considered sacrilege by many in typography circles.

  6. theTedd

    If we consider the markup as representing direct styling, your version makes perfect sense; though some would argue WYSIWYG editors have given people the wrong idea about styling ad hoc.

  7. Kev

    I genuinely have no idea why Markdown threw away years (decades?) of people using *bold* /italic/ and _underline_ to do their own thing without any obvious benefit.

  8. singpolyma

    theTedd: we don't do that doubling thing though

  9. singpolyma

    we use _ for em and * for strong becauase _ as italic does have some history also

  10. singpolyma

    but I agree / was more common

  11. theTedd

    > theTedd: we don't do that doubling thing though I didn't suggest we did, just explaining where it comes from (as it's used in some markdown dialects)

  12. singpolyma

    and there's no reason client's can't/shouldn't support it on send if they like

  13. singpolyma

    Just like people seem very divided if formatting toolbar buttons are worth it

  14. theTedd

    Toolbars and menus are useful for discovery; once people are familiar with the tools and shortcuts, they feel less necessary. There is an unfortunate fashion for removing/hiding everything for the sake of a 'clean' look, which designers love, but it's form over functionality.

  15. pep.

    "Kev> I genuinely have no idea why Markdown threw away years (decades?) of people using *bold* /italic/ and _underline_ to do their own thing without any obvious benefit." "people"? You mean some people in the west? :)

  16. Kev

    Sure. Were there competing non-Western standards back in the 90s and thereabouts?

  17. Kev

    Sure. Were there competing non-Western standards on the Internet back in the 90s and thereabouts?

  18. pep.

    There still are many anywhere in the world

  19. pep.

    There still are many everywhere in the world

  20. Kev

    Actually, 80s, probably, as it was a usenet thing, amongst others (orgmode etc.), I just wasn't on the Internet until the 90s.

  21. pep.

    You wouldn't even need to worry about them just like you do now, if we just cared about what's sent over the wire :)

  22. theTedd

    *cough* 0394 *cough*

  23. Kev

    Markdown is an input format rather than a wire format.

  24. pep.

    Yeah, hence forcing markdown over every single client being a really bad choice

  25. theTedd

    Markdown is a quick hack for inserting styling information

  26. theTedd

    Like most quick hacks, everyone copies it (because it's quick and easy) and thus it becomes immortal

  27. moparisthebest

    What 393 defines well predates markdown in XMPP, email, IRC, online forums etc etc etc

  28. pep.

    moparisthebest, yeah, as said above, in a very specific part of tech.

  29. pep.

    Different people, different usage

  30. Kev

    > What 393 defines well predates markdown in XMPP, email, IRC, online forums etc etc etc Oh, interesting. What's the provenance?

  31. moparisthebest

    I have no idea but people have been bolding text *like this* for longer than I've been on the internet

  32. Kev

    I have no idea how long you've been on the Internet :D

  33. theTedd

    Since he woke up a few hours ago

  34. moparisthebest

    Early 2ks ? :)

  35. moparisthebest

    Next up: BbCode XEP: https://www.phpbb.com/community/help/bbcode#f0r0 /s

  36. Kev

    Markdown is from the early 2ks, so I'm not sure that's a surprise.

  37. Kev

    But you were claiming that people were using that formatting, rather than the one I'd seen historically on the Internet (long before then) before the Internet?

  38. theTedd

    If it's a competition, I expect THIS was the original emphasis format

  39. moparisthebest

    Wikipedia says markdown was 2004, I was talking 2000-2001 or so

  40. Kev

    The question still stands - if using 393-style styling predates the Internet, where does it come from?

  41. pep.

    None of this actually matters if we only cared about the wire format

  42. pep.

    None of this actually matters if we only care about the wire format

  43. theTedd

    *cough* 0394 *cough*

  44. singpolyma

    pep.: indeed. There's no reason the ui has to match the wire format. That's what I was saying. Client can use buttons, markdown, /, whatever it wants for it's own input boxes

  45. pep.

    That's what I've been saying for.. 5 years now?

  46. Kev

    I'm not aware that anyone has, at any point, claimed otherwise.

  47. Kev

    Just a question of whether it's pragmatic to do something markdownish, or not.

  48. moparisthebest

    > The question still stands - if using 393-style styling predates the Internet, where does it come from? Kev: will synchronet is a BBS still in active development from 1991 http://wiki.synchro.net/ref:markup

  49. moparisthebest

    I doubt it invented the format

  50. pep.

    "I'm not aware that anyone has, at any point, claimed otherwise." actually.. yes, it comes up every single time there's a remake of xhtml-im vs styling

  51. Kev

    > > The question still stands - if using 393-style styling predates the Internet, where does it come from? > : will synchronet is a BBS still in active development from 1991 http://wiki.synchro.net/ref:markup Yes, that's the style I was claiming was in common use pre-markdown, not the 393 style :)

  52. Kev

    > "I'm not aware that anyone has, at any point, claimed otherwise." actually.. yes, it comes up every single time there's a remake of xhtml-im vs styling Really? Someone claims that it is technically impossible to have a UI distinct from wire protocol?

  53. pep.

    Well otherwise we would have given up 393 already

  54. pep.

    Because it's not possible to use this as the wire format

  55. pep.

    Due to sigils being added as is to <body/>

  56. pep.

    It's just impossible to get the sender's intent

  57. Kev

    People claim that it's not worth the effort, or that particular wire protocol proposals are unpleasant (which they are), but I don't recall anyone making the argument that it's technically impossible to have UI distinct from protocol.

  58. singpolyma

    pep.: it is a wire format so I disagree that it's impossible to use it as what it is

  59. moparisthebest

    > It's just impossible to get the sender's intent Because you don't know the senders intent, when I do *this* I mean bold except when I don't

  60. singpolyma

    If you don't you add the unstyled tag

  61. singpolyma

    So saith the xep

  62. theTedd

    People have been using various forms of 'markup' to apply emphasis into their text since they were using typewriters - whether they used _this form_ or *this form* or LIKE THIS or [this way] or even 'this way'; 0393 just attempts to standardize one form as an evolution of what appeared to be already in common use (for some corners of the internet)

  63. theTedd

    > Because you don't know the senders intent, when I do *this* I mean bold except when I don't You don't mean bold, you mean emphasis and you want to represent that emphasis using bold

  64. moparisthebest

    Also I don't want a WYSIWYG editor in my messenger

  65. moparisthebest

    Again I meant *this* as bold 20 years so, what 393 says doesn't matter, it's just sensible rules to unify behavior instead of each client doing it's own things

  66. moparisthebest

    Again I meant *this* as bold 20 years ago, what 393 says doesn't matter, it's just sensible rules to unify behavior instead of each client doing it's own things

  67. pep.

    moparisthebest, on the wire, I'm all for it. As input format, I'd rather not force anyone into anything

  68. pep.

    The thing is atm I don't have a choice but to read the 393 you send me.

  69. pep.

    My client can't even ignore it because parsing that is a mess. Also the sole fact that I have to opt-out of it is a pain

  70. moparisthebest

    it's an input format that has existed forever (in internet terms) you'll never stop people from sending that way

  71. moparisthebest

    I'm all for defining a richer wire format, but 393 is still sensible for displaying plain text imho

  72. pep.

    Fine. Then implement it on top of a wire format that is specified

  73. Kev

    394 has assorted issues that make it impractical to use, but I'm not tied to sending input markup on the wire - currently we have no better solution, though, and you're not going to stop people typing with sigils, so ...

  74. pep.

    Kev, not that I'm not personally talking about 394. I just don't want 393

  75. theTedd

    You won't stop people from _typing_ it that way, but your client doesn't have to _send_ that

  76. Kev

    Yes, that's what I was saying.

  77. pep.

    And also, clients can accompagny users into using the wire format

  78. larma

    Kev, can you list some of the issues wit 394?

  79. Kev

    Unless we have something better than sending sigils on the wire (and it's not 394), then clients won't be doing anything with the sigils that people are already typing in their input.

  80. Kev

    > , can you list some of the issues wit 394? No overlap with the spans is a big one.

  81. pep.

    We do. We did, until it was killed with fire for bonkers' reasons

  82. moparisthebest

    Sorry what do you expect my client to do when I type *this* ? Assume I mean bold and send that bolded on the wire? That's not right

  83. pep.

    moparisthebest, if you expect your client to not have a clue how to interpret your typing, how do you expect mine receiving it :)

  84. MSavoritias (fae,ve)

    Isnt that what its doing now?

  85. Kev

    > Sorry what do you expect my client to do when I type *this* ? Assume I mean bold and send that bolded on the wire? That's not right As long as it's obvious to the user that that's what is being done (e.g. showing it as such in the input prior to sending), that's a client's choice, I Think.

  86. theTedd

    > Sorry what do you expect my client to do when I type *this* ? Assume I mean bold and send that bolded on the wire? That's not right What do you expect any client to display when you type *this* and how is that different?

  87. moparisthebest

    pep.: I expect the human to interpret my typing, that's why 393 doesn't add or remove characters

  88. Kev

    And that's a problem with 393 :)

  89. singpolyma

    I dont think "doesn't add or remove characters" is true

  90. singpolyma

    Sime clients choose not to

  91. singpolyma

    But the spec is just a wire format

  92. Kev

    393 says not to, IIRC.

  93. moparisthebest

    I don't *care* what clients display when I type *this*, it's obvious by context when I mean bold vs not

  94. pep.

    moparisthebest, https://codeberg.org/poezio/poezio/issues/3455#issuecomment-965383

  95. larma

    > No overlap with the spans is a big one. Can you explain why that's a big issue? It doesn't seem to me.

  96. moparisthebest

    If they take away the * then I get upset

  97. theTedd steals all of moparisthebest's *s

  98. singpolyma

    If you want that you need to send unstyled tag

  99. Kev

    unstyled is for not applying styling. It's a SHOULD that you also render the sigils.

  100. larma

    > It is RECOMMENDED that styling directives be displayed and formatted in the same manner as the text they apply to

  101. moparisthebest

    > But the spec is just a wire format Ah I see, I think that's the disconnect here I agree 393 would be a bad wire format *if* it was a wire format, but it's not a wire format, it's just documenting a standard and pre-existing way to style plain text messages (instead of what happened before, each client rolling their own)

  102. larma

    393 clearly is a spec defining a wire format

  103. pep.

    ^

  104. moparisthebest

    Hard disagree

  105. larma

    It shouldn't be, but it is

  106. larma

    literally every example puts <body> around the markup to make it absolutely obvious

  107. larma

    literally every example puts <body> around the markup to make it absolutely obvious, that this is on wire

  108. MSavoritias (fae,ve)

    if its not a wire format i dont see why it was pushed instead of xhtml anyway

  109. pep.

    Also the spec would have hinted towards using some kind of wire format if it was only an input format

  110. larma

    MSavoritias (fae,ve), it wasn't "pushed". Some implemented it and others had to comply because clients started to send weird bodies with sigils in them

  111. singpolyma

    It would be inappropriate for any xep to spec UI

  112. moparisthebest

    It wasn't pushed, it already existed in most XMPP, IRC, email, and web forum software

  113. MSavoritias (fae,ve)

    well doesnt 393 specs ui basically?

  114. Kev

    I promise that clients were sending sigils in bodies a long long time before 393.

  115. MSavoritias (fae,ve)

    by forcing everybody to use certain characters

  116. Kev

    Certainly back in 2001 :)

  117. moparisthebest

    Again, not a wire format, but sensible rules for displaying plain text

  118. singpolyma

    MSavoritias (fae,ve): no

  119. singpolyma

    Because those characters are just on the wire

  120. pep.

    singpolyma, that's what I used to think too, (speccing UI) but you can't really take out the authors' UX intention when writing a spec. It bleeds all around

  121. moparisthebest

    Gajim at least already supported *bold* years before 393

  122. pep.

    moparisthebest, yeah and that's not the point

  123. MSavoritias (fae,ve)

    > MSavoritias (fae,ve), it wasn't "pushed". Some implemented it and others had to comply because clients started to send weird bodies with sigils in them well the introduction specifically positions itself as an xhtml not security disaster. so the author at least seems to do that

  124. theTedd

    I think I might start formatting my messages with RTF from now on

  125. pep.

    moparisthebest, allow me to ignore it on the receiving side without having to implement my own parser, and then I guess I'll be happy to say that 393 isn't a wire format

  126. MSavoritias (fae,ve)

    > Because those characters are just on the wire it does say in the implementation notes: > 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*".

  127. MSavoritias (fae,ve)

    and then it says to use html/xhtml for accessibility :P

  128. singpolyma

    Sure, that should probably be weakened in order to make is sound less like a UI spec

  129. moparisthebest

    tl;dr I still think we need a real wire format to handle rich text (like xhtml-im or 394), but it's still sensible to display plain text as defined in 393 I *totally* agree it'd be wrong to implement a WYSIWYG editor and then have it spit out '393 plain text But I *also* think it'd be totally wrong to pretend '393 is an input format and parse it into xhtml-im/394 on the sending client

  130. singpolyma

    I disagree with both of those

  131. singpolyma

    393 is a totally sane wire format for an editor UI

  132. singpolyma

    And also not a terrible input format, though that's unrelated to the xep itself of course

  133. larma

    > I think I might start formatting my messages with RTF from now on If you'd be authoring one or two of the major clients, doing that might actually work 😉

  134. Kev

    For those who care, I just took a trip down memory lane. I believe Psi was the first XMPP client to render sigils, which it started doing Jan 4th 2004, using the existing *bold* /italic/ _underline_ conventions that people had been sending anyway (which is why it made sense* to start rendering them). [ * to me ]

  135. singpolyma

    Google Talk also did it

  136. singpolyma

    About that same time

  137. Kev

    I thought Google Talk wasn't released until way after that?

  138. singpolyma

    Pretty sure it was released 2004

  139. Kev

    Late 2005, by the look of it.

  140. singpolyma

    Ah ok, one year off. Close ;)

  141. moparisthebest

    We could just use this so that no one is pleased: https://modern.ircdocs.horse/formatting

  142. dan.caseley

    I've looked at XHTML-IM, 393 and 394. 393 seems to be "Let's all agree that this means bold and this means italic, then we can optionally style in our client appropriately" The other two require client understanding of the extra elements that accompany the message body. Question: Could all three be supported by a client without overlap or confusion? Are there any additional standards that we should include in this conversation, e.g. a standard that uses server support to honour client preferences, to deliver plain text to my phone but rich text to my desktop

  143. larma

    dan.caseley, XHTML-IM does not use what is in <body> so it can be used alongside a regular body or anything else in the same message for forwards and backwards compatibility. 393 modifies the content of <body> and thus is incompatible with anything else that tries to use that. However the modified body of 393 is still displayed to the user, that's why you see *stars around this bold text*. 394 adds styling without modifying the <body>, but still relies on its content. That means that if you wanted to send a message with a single word bold, you would need to add stars to its <body> in 393 and those stars would then be displayed to users even if your message also contains styling using 394. There was a proposal to add the power to 394 to optionally remove the stars added by 393 before rendering, but it defeats the purpose of 394 (to not touch the content of <body>, but only the styling)

  144. dan.caseley

    Does 393 modify the body? Or just modify the rendering of that body?

  145. dan.caseley

    If I was already sending _emphasis_ isn't 393 just about how it's shown?

  146. Kev

    It doesn't modify anything, it's just convention.

  147. dan.caseley

    Ace. That was my reading too.

  148. larma

    Well, it instructs the sender to put _underscores_ in the body to emphasis. So in that sense it instructs the sender (either the human or the client) to modify the body

  149. dan.caseley

    Of course, if I was previously going to use /emphasis/ and now needed to use underscores, there is a modification, but it's not in code (except maybe some UI buttons?)

  150. dan.caseley

    Yeah, that.

  151. Kev

    Long ago, people used to send *bold* /italic/ _underline_ to emphasise their text, so some clients decided to start rendering those in the same way. 393 is, roughly, a codification of similar (although different) rules.

  152. dan.caseley

    MEBCAK?

  153. Kev

    (I think I was the first XMPP client author to start doing so, in Psi in Jan 2004)

  154. larma

    With XHTML-IM, you could do emphasis without putting underscores in your body. You would just instruct the client to put emphasis on the word

  155. dan.caseley

    I don't disagree with 393. I probably disagree that it supercedes 71, since it provides an alternative.

  156. larma

    i.e. by pressing Ctrl-I while typing to switch to emphasis mode

  157. Kev

    Well, it's not really an alternative.

  158. Kev

    Or, well, it is. But it isn't.

  159. dan.caseley

    Its an alternative for a subset of use cases.

  160. dan.caseley

    XHTML is clearly offering a lot more.

  161. dan.caseley

    but_at_what_cost.gif

  162. larma

    393 is essentially "we have this ancient notation that we started to use to put emphasis on words when we had no markup commands. Let's use that notation to actually apply markup"

  163. Kev

    I note that people's expectations of what they can represent has drastically changed over time.

  164. larma

    You mean, rich text became a thing on the internet and people now expect they can do it?

  165. MSavoritias (fae,ve)

    xhtml and 393 are two different usecases imo

  166. MSavoritias (fae,ve)

    idk what 394 aims at

  167. moparisthebest

    Wait which way do you mean?

  168. Kev

    I would *never* have imagined in the old days that I would have been able to represent * This * Nested * List * of * Items and ```rust code ``` inside my `xmpp` client, > but now I expect all those sorts of thing to work.

  169. Kev

    (And before anyone points it out, I realise that all of those are semantics rather than rendering instructions)

  170. larma

    394 is IMO a replacement to XHTML-IM in how it works, except that it _currently_ does not have the same feature set

  171. moparisthebest

    I remember MSN messenger had a WYSIWYG editor in the early/mid 2ks and now everyone uses SMS with no possible markup at all

  172. Kev

    (And I also note that I don't claim that my example above should be the wire representation - although everyone understood what I was trying to say in all of that, without any additional presentation markup)

  173. MSavoritias (fae,ve)

    394 needs to be extended by a *lot* to be anything close. and at that point you have html but the xmpp version :)

  174. Kev

    > HTML but the XMPP version I don't see that's *necessarily* a bad thing.

  175. larma

    MSavoritias (fae,ve), the important parts are, that 1) you don't have two alternative contents, it's just one body. And 2) it's not HTML, but direct markup instructions

  176. Kev

    The main thing to like about 394, in my view, is that there's no duplicated body.

  177. MSavoritias (fae,ve)

    if thats what we want to do maybe. but it needs the scope to widen imo

  178. Kev

    Duplicated bodies cause a lot of problems, for a subset of people. I happy to be one of them.

  179. moparisthebest

    Also worth noting you can't do currently-deployed-e2e with xhtml-im but can with 393 and 394

  180. moparisthebest

    They are kinda orthogonal but kinda not

  181. moparisthebest

    > The main thing to like about 394, in my view, is that there's no duplicated body. Yes agreed, but it probably also limits what you can do? It's trade-offs all the way down

  182. Kev

    Is there a necessary tradeoff between inline markup and external markup? I suspect there doesn't need to be.

  183. MSavoritias (fae,ve)

    current as in omemo?

  184. dan.caseley

    > The main thing to like about 394, in my view, is that there's no duplicated body. I also like this. I also consider that a future XEP could introduce server support for client preferences for folk who want fewer bytes.

  185. Kev

    394 *does* have tradeoffs, and is an external markup example, but I don't think that means 394 and external markup are synonymous.

  186. larma

    moparisthebest, 394 markup instructions are not encrypted (leaking metadata)

  187. moparisthebest

    Right, but not content

  188. larma

    MSavoritias (fae,ve), current popular OMEMO and PGP, but not new PGP or new OMEMO

  189. singpolyma

    MSavoritias (fae,ve): current as in omemo1, which only does body content so only 393 style can work with that

  190. singpolyma

    larma: well, you would strip them I hope if doing omemo1

  191. singpolyma

    or convert to 393

  192. moparisthebest

    MSavoritias (fae,ve): current as in the omemo/pgp that all clients implement currently

  193. larma

    Or claim they are not relevant enough 😉

  194. MSavoritias (fae,ve)

    right

  195. moparisthebest

    That also needs fixed and will be eventually

  196. MSavoritias (fae,ve)

    so what we need is an envelope thing like omemo:2 that we can put the markup stuff in there

  197. moparisthebest

    But at this moment in time...

  198. MSavoritias (fae,ve)

    yeah of course. but if we adopt something it should be for the next 20 years

  199. singpolyma

    aaaaaaanyway, the question was "can we undeprecate xhtml-im without having to go to war" and it seems the answer is still no for now so I guess just keep it deprecated for now? :P

  200. Kev

    Somewhat tongue-in-cheek, but also-kinda-not: <markup> <start-html-tag tag="strong" pos="5"/> <end-html-tag tag="strong" pos="10"/> <start-html-tag tag="blink" pos="6"/> <end-html-tag tag="blink" pos="8>/> </markup> XHTML markup, without a duplicated body, and without injection attacks :)

  201. singpolyma

    doesn't reuse the namespace, which is sad, but does reuse the semantics which is certainly better than totally making up a new thing

  202. larma

    Just for reference (in case anyone cares): WhatsApp does effectively 393, Telegram is like 394, Matrix uses HTML

  203. dan.caseley

    > but now I expect all those sorts of thing > to work. You're describing a Consistency Heuristic. In software testing theory, it's a potential quality problem if your software is inconsistent with different lenses, like in this instance, inconsistent with the World and other instant messaging software. Slack and other desktop collaboration IM definitely offer rather rich messaging now, even though SMS and Telegram and most other mobile clients offer very little.

  204. larma

    singpolyma, except that many of the semantics of XHTML-IM is actually bad for various reasons (e.g. full custom color support, as discussed before)

  205. singpolyma

    xhtml doesn't actually have that, but if you add css sure

  206. Kev

    > Consistency Heuristic The point I was making wasn't that, it was that although I started (I think) the trend of rendering sigils in XMPP, it was a different world with different expectations back then, so it doesn't mean I'm arguing that a week off 20 years on, it's still the state of the art.

  207. singpolyma

    it's a sensible fallback for clients that don't have xhtml-im I think

  208. singpolyma

    and since those same clients have self-selected to use it, it works out that way

  209. larma

    https://core.telegram.org/type/MessageEntity

  210. singpolyma

    yeah, I'm aware telegram does spans

  211. larma

    Not sure which person decided that it's important you can tag that a part of the message is a bank card number 😉

  212. singpolyma

    looks like they don't support lists at all

  213. Kev

    I use lists far more often that I probably should in chat.

  214. larma

    • I think not having real support for lists is fair • because we do have unicode bullets for that

  215. singpolyma

    sigils again, sure

  216. larma

    What you might need is indentation though

  217. Kev

    * we have ASCII bullets, too :)

  218. singpolyma

    if we're just doing with text you can use space or \t same as anywhere for indent

  219. larma

    unicode bullets are not an ASCII character that is similar to what should be displayed, it IS what should be displayed

  220. Kev

    > unicode bullets are not an ASCII character that is similar to what should be displayed, it IS what should be displayed I realise. Maybe the ':)' sigil didn't do its job.

  221. larma

    \t does not indent multiline text

  222. singpolyma

    oh you mean indent in the face of wrapping

  223. larma

    The only thing unicode bullets do not do is to indent wrapped lines, otherwise they would be totally fine for lists

  224. MSavoritias (fae,ve)

    So we expect people to look for the unicode list bulletpoint? Interesting

  225. larma

    How clients allow input and how we transfer on wire are totally independent topics

  226. singpolyma

    agreed

  227. larma

    Markdown editors nowadays have fancy table editors, they don't expect users to enter 50 - just to add a new row to the table 😉

  228. singpolyma

    is there a reason https://xmpp.org/extensions/xep-0115.html isn't final yet? people are already working on replacing it...

  229. larma

    singpolyma, I guess nobody likes to put a Final sign on things while they have security issues

  230. singpolyma

    right, but I think the plan is to not fix the security issues and instead switch to a new xep?

  231. larma

    It's not fixable, so yes

  232. larma

    It's not fixable without breaking compatibility, so yes

  233. larma

    It's not fixable without breaking compatibility, which is not allowed in Stable, so yes

  234. singpolyma

    so should we be talking about moving to deprecated then?

  235. singpolyma

    uhm... https://xmpp.org/extensions/xep-0424.html says last call ended almost two years ago? but also it just received a major breaking change. I assume just a mistake in the header and it should be experimental?

  236. singpolyma

    https://xmpp.org/extensions/xep-0425.html says the same

  237. daniel

    Yes. Council voted on putting it back to experimental

  238. singpolyma

    ok, so just a metadata issue

  239. singpolyma

    I've started a list of xeps in compliance suite which need advancement, to track: https://wiki.xmpp.org/web/User:Singpolyma/XEPs

  240. moparisthebest

    think we can LC 2 per week maybe?

  241. pep.

    "it's not HTML", larma, it was never HTML :P

  242. pep.

    "it's not HTML", larma, it never was HTML :P

  243. pep.

    "Also worth noting you can't do currently-deployed-e2e with xhtml-im but can with 393 and 394" moparisthebest, that's an issue with the currently-deployed-e2e specs though

  244. pep.

    "Yes. Council voted on putting it back to experimental" maybe we should keep track of what happened to the spec and why in the spec itself?

  245. singpolyma

    I think "what happened" (current status) we do it seems these two just fell through the cracks

  246. moparisthebest

    > "Also worth noting you can't do currently-deployed-e2e with xhtml-im but can with 393 and 394" moparisthebest, that's an issue with the currently-deployed-e2e specs though 💯 but still worth noting