jdev - 2026-03-03

  1. detente

    is there a standard wayy to do colored text in XMPP or in a XEP? ✎

  2. snit

    in xep-0421, it says: > Additionally, a MUC service SHOULD generate the identifier such that the occupant identifier of a user in one room of the service does not match the occupant identifier of the same user in another room of the same service. If the MUC service generates the same occupant identifier for the same user in different rooms, information shared using different nicknames and in different rooms could be combined through the occupant identifier and thereby unintentionally reveal information about the user. for one, what kinds of information leakage is the xep trying to prevent here? i'm finding it increasingly annoying that there's seemingly no way to tell whether two users in two semi-anon rooms are the same person or not secondly, assuming whatever leakage prevention is fair and valid, would it make sense to have a XEP defining an _opt-in_ identifier clients can send that hides the JID, but remains the same across MUCs? the main use-case i'm thinking about here is being able to hover over a user in a room and get your usual "mutual rooms" and "also known by" info you see in a lot of other platforms.

  3. detente

    is there a standard way to do colored text in XMPP or in a XEP? ✏

  4. snit

    > is there a standard way to do colored text in XMPP or in a XEP? i know there's a way to _generate_ a colour based on text, but i don't think you can send messages _with_ colours, if that's what you're asking ↺

  5. detente

    yeah it's the latter

  6. wgreenhouse

    it's covered by xhtml-im, so you'd need a convenient way to edit that in an xhtml-im client

  7. theTedd

    detente, https://xmpp.org/extensions/xep-0071.html

    👍 1
  8. dwd

    There used to be XHTML-IM, but that was ditched because it tended to end up being a security nightmare.

  9. wgreenhouse

    poezio for example still supports it, at least in a receiving direction (and uses it to render IRC colors from biboumi)

  10. detente

    yeah that XEP is deprecated

  11. detente

    i think something much more minimal could be defined

  12. snit

    maybe if my beloved XEP-0394 (markup) gains wider support, an extension for colours could be defined :D

  13. detente

    i don't think we need webpages in XMPP but we could use some basic formatting, the kind of stuff even IRC can do already

  14. theTedd

    An extension to XEP-0394 would be my preference too

  15. wgreenhouse

    I think xhtml-im is fine tbh, if restricted to local content only the worst one can imagine is billion-laughs-style memory exhaustion attacks, which you shouldn't be building an xmpp client around a bad xml library anyway

    👍 1
  16. detente

    eh, i don't think it's necessary to implement so much

  17. snit

    if i understand 0394 correctly, something as simple as the following should work: ``` <message> <body>THIS has colour !!</body> <markup xmlns='urn:xmpp:markup:0'> <color xmlns='urn:xmpp:color:0' begin='0' end='4' color='#FFFFFF' /> </message> ```

  18. wgreenhouse

    snit: hmm, 394 already specifies that, and we just need clients with convenient editors?

  19. snit

    it defines the markup format but not the color element

  20. snit

    so you'd want to either make a new XEP for colours, or add it to 0394. 0394 itself seems to explicitly encourage extension to new markup in separate specifications as well

  21. snit

    and then yeah all you'd need is client-side editor support

  22. snit

    > in xep-0421, it says: > > Additionally, a MUC service SHOULD generate the identifier such that the occupant identifier of a user in one room of the service does not match the occupant identifier of the same user in another room of the same service. If the MUC service generates the same occupant identifier for the same user in different rooms, information shared using different nicknames and in different rooms could be combined through the occupant identifier and thereby unintentionally reveal information about the user. > for one, what kinds of information leakage is the xep trying to prevent here? i'm finding it increasingly annoying that there's seemingly no way to tell whether two users in two semi-anon rooms are the same person or not > secondly, assuming whatever leakage prevention is fair and valid, would it make sense to have a XEP defining an _opt-in_ identifier clients can send that hides the JID, but remains the same across MUCs? the main use-case i'm thinking about here is being able to hover over a user in a room and get your usual "mutual rooms" and "also known by" info you see in a lot of other platforms. also not to be annoying but would i be able to get some feedback on this ↺

  23. theTedd

    Anonymity in semi-/anon MUCs is expected, so linking identities by default is a definite no; opt-in might be possible, but how many people would choose to do that?

  24. snit

    hard to say; the only answer i've ever seen about why semi-anon exists is to hide JIDs to prevent dm/invite spam and such, so it doesn't seem like most people expect joining two different rooms on the same account without being known as the same person to be a use-case. i'd certainly opt-in, and i brought this up because its come up a few times in another muc i'm in, so i reckon its something a number of people would want (i certainly would) ✎

  25. snit

    hard to say; the only answer i've ever seen about why semi-anon exists is to hide JIDs to prevent dm/invite spam and such, so it doesn't seem like most people expect joining two different rooms on the same account without being known as the same person to be a use-case. i'd certainly opt-in, and i brought this up because its come up a few times in another muc i'm in, so i reckon its something a number of people would want ✏

  26. jackhill

    should xhtml-im be un-deprecated?

  27. dwd

    snit, I think there's a good argument that occupant-ids should be stable in rooms within the same Space.

  28. jackhill

    have we gotten better at sandboxed xhtml handling? Have all these email and webmail apps pushed the state-of-the-art forward?

  29. detente

    sandbox escapes exist

  30. theTedd

    dwd, `spaces-id` - just one more id, bro, then we've fixed it, bro!

  31. detente

    plus i don't know if everyone wants to make such a heavy client

  32. dwd

    jackhill, Sandboxing isn't much of a problem, but it gets nastier in messaging because you often want to, for example, cut and paste entire conversations (or at least multiple messages) and that's very hard to achieve with sandboxed individual messages.

  33. dwd

    theTedd, All problems in computer science can be fixed with another level of indirection?

  34. theTedd

    `id-id` that links all other ids together!

  35. snit

    > dwd, `spaces-id` - just one more id, bro, then we've fixed it, bro! we need separate ids each that are: stable in one room, stable in one space's rooms, stable in all rooms, stable globally !! ↺

  36. dwd

    theTedd, I feel a XEP coming on for publication just after the end of the month.

  37. singpolyma

    > should xhtml-im be un-deprecated? yes ↺

  38. theTedd

    > should xhtml-im be un-deprecated? Can devs be trusted not just to throw whatever they receive at a generic HTML renderer? This is the reason it was deprecated. ↺

  39. dwd

    Not just that reason, even.

  40. dwd

    Beyond that, both the markup and markdown XEPs were built to ensure that whether you looked at the rich or plain version of a message, you'd see the same message, which avoids various attacks (of the phishing kind of nature).

  41. dwd

    And then there was the UX of the safe ways of handling this in a webapp.

  42. singpolyma

    >> should xhtml-im be un-deprecated? > Can devs be trusted not just to throw whatever they receive at a generic HTML renderer? This is the reason it was deprecated. anyone putting unsanitized html into a web browser context is going to have other problems ↺

  43. dwd

    singpolyma, They did...

  44. theTedd

    Sure, but if the spec is large and complex enough, it basically encourages doing that over implementing it yourself

  45. singpolyma

    we still have people doig this today, putting the current styling content into a markdown parser (which doesn't even work...) and then the raw output into a browser. some people are just determined to break every best practise

  46. theTedd

    It's less intentional and more laziness

  47. singpolyma

    > Sure, but if the spec is large and complex enough, it basically encourages doing that over implementing it yourself well, you should definitely use off the shelf HTML stuff ↺

  48. singpolyma

    but need to either sanitize (using an off the shelf sanitizer) or use a real renderer and not a browser or web view

  49. singpolyma

    I agree the attempt in xhtml-im to define a "subset" of html was a bit silly

  50. dwd

    It's a profile of XHTML (obviously!) but that was the guidance from the W3C I think, back in the day.

  51. jonas’

    singpolyma, it help(s|ed) to be able to render in more minimal contexts though

  52. detente

    i don't think it's great to have the only option for colors and basic formatting be something that implies having a HTML renderer

  53. singpolyma

    jonas’: you mean being able to assume no one is using anything you aren't aware of? Except then in practise you'll need to check for other things anyway

  54. singpolyma

    detente: basically every UI framework has an HTML renderer built in anyway

  55. singpolyma

    that's why every protocol uses it

  56. singpolyma

    though it's pretty trivial to build your own, I've done it a few times

  57. detente

    a huge mistake in my opinion

  58. singpolyma

    why?

  59. jonas’

    singpolyma, oh, yeah, not for security purposes, clearly.

  60. jonas’

    but for interop purposes.

  61. singpolyma

    having suggestions of stuff that is likely to be common I guess would be ok

  62. detente

    complexity, practically requiring sandboxing these days, increased system resource use, and generally unnecessary levels of formatting

  63. singpolyma

    but I'd never want to rule out allowing other stuff

  64. singpolyma

    no sandboxing is required. there's no executable code

  65. singpolyma

    it's fundamentally the same as message styling just a different syntax

  66. singpolyma

    ironically it is "hardest" to do right in a web client

  67. singpolyma

    but most web frameworks are also used to this problem

  68. detente

    ideally if it remains just HTML only with no additions like HTML5 that essentially imply JS... but then you can use any markup language you want at that point

  69. singpolyma

    HTML5 is just HTML, there's no javascript :)

  70. singpolyma

    neither CSS nor JavaScript is necessarily involved. certainly JavaScript must not be supported that would be bonkers

  71. detente

    some tags essentially imply it but ok

  72. snit

    wait, you mean i can't send arbitrary code and expect them to run it?? smh

  73. theTedd

    Sandboxing wouldn't be required, except when devs blindly throw content at a browser window, and then they're executing any JS you send them. Yes they _should_ sanitise, as they _should_ do many other things, but experience shows that they do not.

  74. singpolyma

    indeed. and those who do not the deprecation does not help, as they also put the raw text in unescaped, or run in through a markdown parser without sanitizing, and many other problems

  75. jackhill

    snit: for that there's WebXDC 😜

  76. theTedd

    So offering people a box full of footguns maybe isn't the best way to go about it

  77. singpolyma

    > snit: for that there's WebXDC 😜 indeed. WebXDC is a very different beast and these objections very much do apply to it ↺

  78. singpolyma

    but departing from the standard format for text formatting which everything else uses just because some people hold it wrong... seems extreme to me

  79. detente

    you'd have to define what "HTML" is as well, as theres the Living Standard HTML of today, HTML4.01, HTML5, the earlier versions of HTML, etc...