jdev - 2023-01-26

  1. Arne

    Hi, I'm thinking about applying for a membership in the XMPP Standards Foundation. Would anyone create an wiki account for me with the Nickname "Arne"? Thank you!

  2. Ge0rG

    Arne: I can do that, please also send me your email address via DM

  3. Arne

    Ge0rG it's arne-bruen@monocles.de thanks

  4. Ge0rG

    Arne: > The user account for Arne (talk) has been created.

  5. Ge0rG

    please check your inbox (and spam)

  6. Arne

    Received. Thanks!

  7. nicoco

    if I'm an entity not implementing last message correction, is it OK to reply to an LMC-containing message with <message type=error>? The statu quo seems to be "just display the message body as a new message", but I am wondering if there something inherently wrong with replying with <message t=error>

  8. MattJ

    What's the benefit?

  9. MattJ

    The reason it's designed the way it is, is so that if someone doesn't support the XEP they still get to see the corrected message

  10. nicoco

    yes, I figured. it's how slidge does it for legacy services that don't support LMC, but it's been confusing to some users. I'll just make the gateway component send a message informing the user that LMC does not work on XXX and that a new message has been sent instead. (well unless the legacy service supports retraction in this case I can retract/send a new one)

  11. nicoco

    I agree that there is no point, I was just trying to think what the "least confusing UX" could be.

  12. Zash

    Hmmmmmmmmmmm, <error type=continue>?

  13. Zash

    I'm not aware of anything anywhere using type=continue, ever, in the entire history of XMPP.

  14. nicoco

    I have found at least one client that does not display any hint that the correction stanza has been replied with an error, I think that's not good because I guess the stanza can have been rejected for another reason, so it would make sense to show in the UI that the correction did *not* work. I'll open a ticket :)

  15. Zash

    Yes, improve error handling!

  16. MattJ

    I agree, errors are possible

  17. Zash

    Would <error type=continue> be appropriate for cases where you strip some extension and carry on?

  18. flow assumes that many clients are not properly reporting xmpp-level errors to the user (for example, because it's hard to do so, without confusing the user)

  19. Kev

    What to do with errors as a client is *hard*.

  20. Kev

    What flow says :)

  21. flow

    yeay \o/

  22. nicoco

    yes. this "LMC error" case is indeed tricky. in general I find GUIs extremely hard to code, and user feedback about GUIs "surprising", so I'm not blaming anyone =)

  23. MattJ

    Yep, I'm not saying it's not hard, just that it should be handled :)

  24. nicoco

    since we're talking error handling, xep 0086 is "deprecated" but I still use https://xmpp.org/extensions/xep-0086.html#table-1 to decide error conditions and types. am I going to go the XMPP jail for this?

  25. Zash

    🚨️🚨️🚨️ GET THEM!

  26. MattJ

    nicoco, yes, you should use RFC 6120 to determine those

  27. MattJ

    If it matches, you're fine

  28. MattJ

    or if you use common sense, you'll probably also be fine :)

  29. Zash

    Bookmark https://xmpp.org/rfcs/rfc6120.html#stanzas-error

  30. MattJ

    If you use the 'code' attribute, go directly to XMPP jail, do not pass Go, do not collect compliance badges

  31. Zash hides the util.error `code` support

  32. flow hands out "get out of xmpp jail" cards

  33. pep.

    Does /me usage get you a "get in the geek circle" card? :P

  34. nicoco

    oh thanks for the link, this is a bit better than this obscure table. Some subtleties like difference registration-required and subscription-required are a bit confusing to me, but I need to read in details

  35. flow

    no, just in the "old timer geek circle" (obviously)

  36. nicoco

    btw, since we're mentioning error handling, slixmpp tends to create stanzas like this: ```xml <message xmlns=jabber:component:accept> <error xmlns=jabber:client>... ``` that's a slixmpp bug, right? no reason to switch to another namespace in the error, it should just be <error> here, right?

  37. pep.

    I'd say that's a bug yeah, maybe someone can confirm

  38. MattJ

    Yes, a bug. The jabber:component:accept namespace has its own <error> (with exactly the same format as jabber:client)

  39. wurstsalat

    > do not collect compliance badges :D

  40. Zash

    Unify the namespaces!

  41. nicoco

    pep. this happens when I just `raise XMPPError('condition', 'text')` in a handler which is very convenient, but apparently does not handle the component case well. I tried to fix but got lost in low level stream stuff that I don't master at all. just saying that in case you want to have a look :P

  42. pep.

    I also probably don't have the knowledge to dig in there.. poke mathieui :x

  43. nicoco

    Hehe OK, I will start by opening an issue I guess.

  44. Link Mauve

    larma, moparisthebest, fyi biboumi’s limits aren’t in chars per messages, but in bytes per IRC command, which would make advertising that to the XMPP client very awkward. For instance, the recipient’s name is also part of the limit.

  45. Link Mauve

    larma, another interesting use case I haven’t seen mentioned in this discussion is game MUCs, where it is an expected feature that not all users receive the same messages (or truth as you called it), and that your messages (e.g. “go left”) will get rewritten or even silently discarded (e.g. “your character went to the left room” from the narrator).

  46. Link Mauve

    You can’t encode this kind of rules in a generic protocol.

  47. larma

    Not sure what exactly a game MUC is supposed to be, but if it's not a groupchat, that usecase is totally out of scope of the MUC protocol

  48. Link Mauve

    larma, https://en.wikipedia.org/wiki/MUD

  49. Link Mauve

    It is a groupchat, just for a different usecase than what we’re using here.

  50. larma

    Is it a groupchat or is it "you send messages to some server. multiple people are interacting with the same server to play a game"

  51. Link Mauve

    Why does it matter?

  52. larma

    I know text-based, dial-in multi user games, but I wouldn't consider this as a MUC

  53. larma

    And that matters because you're complaining about MUC not being compatible with something that MUC is not supposed to be used for

  54. MattJ

    Always trying to spoil our fun

  55. larma

    If you'd realize this by just having a "bot" user, that people write and get messages with information about the other players, it would work as good without having any compatibility issues

  56. larma

    If you'd implement this by just having a "bot" user, that people write and get messages with information about the other players, it would work as good without having any compatibility issues

  57. MattJ

    xmoo allowed you to navigate between "rooms" and the presence list would update according to who was in the same room

  58. larma

    which you can also entirely do without MUC

  59. larma

    presences work with normal users as well 😉

  60. Zash

    and without XMPP

  61. pep.

    larma, so if I wanted some groupchat-looking thing for my game I'd need to reimplement almost all MUC and not call it MUC?

  62. MattJ

    Clients wouldn't render that, or I don't know what you mean

  63. pep.

    I mean I'm fine, we can have extensions on top of MUC that say "This is MUC+foo" and it behaves this way

  64. larma

    In Dino and Gajim I can see the list of currently online devices

  65. larma

    Not sure about others

  66. larma

    pep., IMO the main idea behind MUC is "Send a message to the service, the service forwards that message (as is) to all participants in the room". If you're not doing that anymore, it's not MUC

  67. Kev

    MUCs modifying the messages that are sent to them is a very long-standing thing in XMPP.

  68. larma

    Kev, this is not about what is a long-standing thing but what is a good idea 😉

  69. Kev

    Be it pastebins, security labelling, whatever.

  70. larma

    There may be valid cases where special behavior of a MUC beyond forwarding are desired

  71. larma

    but that's not what we primarily design the specification around

  72. Kev

    It's not, but it works fine with it.

  73. larma

    Except when it doesn't

  74. larma

    I mean, security labels and pastebin are probably not very invasive, so they're unlikely to cause big harm

  75. larma

    But forwarding a message only to a subset of occupants or modifying it differently by recipient is going to cause trouble with all kinds of extensions we have in MUC nowadays that are designed around the assumption that this wouldn't happen

  76. larma

    > Messages sent within multi-user chat rooms are of a special type "groupchat" and are addressed to the room itself (room@service), then reflected to all occupants. This is from the requirements of XEP-0045

  77. MattJ


  78. MattJ

    FWIW in all this recent discussion about this kind of thing, I don't disagree much with what you've said

  79. MattJ

    I'm the original author of mod_pastebin and a couple of other modules that do "interesting things"

  80. MattJ

    I don't regret writing them, and many of them are innovative, fun and sometimes even useful

  81. MattJ

    But if a client follows the spec, and doesn't work with them, I don't consider that a bug with the client

  82. larma

    (beside my opinion about these things being not nice and also definitely not in the spirit of the spec, we should probaly improve support for these things in Dino for compatibility reasons)

  83. MattJ

    If the module (unintentionally) doesn't follow the spec, it may well be a bug with the module

  84. MattJ

    Sometimes we break certain rules on purpose - I'm pretty sure xmoo violated many sentences in XEP-0045. But it worked in practically all clients, and it was fun to build.

  85. pep.

    What's xmoo?

  86. MattJ

    The pastebin thing... it worked because most clients do just have one hook that handles messages from the MUC, and they use this to update their display/history. I doubt it was even a conscious decision by many of them to treat the MUC as the source of truth, just a convenient implementation approach that avoids the need for tracking/deduplicating reflections. A number of clients didn't/don't work that way, and although it's inconvenient for a user of that module, that's not a bug in those clients.

  87. MattJ

    pep., something like Link Mauve described just now, see also https://en.wikipedia.org/wiki/MOO

  88. pep.


  89. MattJ

    It relied on various non-standard behaviours that happened to work in clients. For example, messages from non-occupants, and messages from the room bare JID

  90. MattJ

    E.g. you might type "stroke cat" and it would reply <message type="groupchat" from="room@server/cat"><body>/me purrs</body></message>

  91. Kev

    Pretty sure 45 allows messages from non-occupants, at least.

  92. Zash

    That's what the on-join history looks like, so yeah

  93. Kev

    """ an implementation MAY allow users with certain privileges (e.g., a room owner, room admin, or service-level admin) to send messages to the room even if those users are not occupants """

  94. nicoco

    back to my boring namespaces issues, is there a list of cases where a component need to sends stanzas where some (direct or indirect) children elements have xmlns=jabber:client? everything's that "forwarded" has to preserve the original namespace and that's it, right?

  95. Kev

    If you're working out when you should rewrite namespaces to :component, I think the sensible rule is that once there is a namespace that isn't the root namespace of the stanza between you and the stanza root in the hierarchy, your namespace should be left alone.

  96. Zash

    Allowing out-of-room entities to send messages to MUC rooms can be ... tricky, implementation wise.

  97. nicoco

    Kev: thanks. so I send from a client with <jabber:client> and then the MUC "echoes" my message but with <jabber:accept:component>, that's OK? same for MUC MAM or history-on-join, they have no reason to have jabber:client anywhere. I didn't have any trouble with this btw, but I'd like to avoid things that "accidentally work" and do things the right way =)

  98. Kev

    I don't follow the question, sorry.

  99. flow

    nicoco, xmpp has the (IMHO) design flaw, that stanza namespaces are hop related and change during the transmission of a stanza. clients should always only see the jabber:client namespace for (top-level) stanzas

  100. flow

    for example, if the muc is a component, then the reflected message will start with jabber:accept:component, when routed to the components server. if the server then routes the message to another server, it will have the jabber:server namespace, and if the final server routes it to the client, then the message will be under the jabber:client namespace

  101. Kev

    You should only receive stanzas in 'your' namespace. It's only a server that has to transform when switching between clients, servers and components.

  102. flow

    right, the namespace transformation is only performed by xmpp servers (at least, I can't think of a counter example)

  103. flow

    right, the namespace transformation is only performed by xmpp servers (at least I can't think of a counter example)

  104. pep.

    Yeah, here in slix it's just because it allows emitting multiple namespaces and does it badly

  105. pep.


  106. qy

    https://repology.org/project/libomemo-c/versions it's spreading

  107. nicoco

    thanks kev and flow. I think there are some bogus jabber:client namespaced (non-top) elements in what slidge sends then. apparently it's not been a problem for clients to handle but I'll change that. I think the only case where I need to make sure I use xmlns=jabber:client is for "messages sent on behalf of normal xmpp accounts", as per https://xmpp.org/extensions/xep-0356.html#sending_mess

  108. Kev

    Inside the <forwarded/> should not be in :component, correct.

  109. Kev

    But every top level stanza you send, as a component, should be.

  110. nicoco

    yes, for the top-level no problem, always :component. what about MAM replies? what shold message/result/forwared/message use? right now slidge does that: ```xml <message xmlns='jabber:component:accept'> <result xmlns='urn:xmpp:mam:2'> <forwarded xmlns='urn:xmpp:forward:0'> <message xmlns='jabber:client'> <body> ``` clients seem to be happy with that, but is that the *right* way?

  111. Kev


  112. Zash

    Probably easiest to always go with `jabber:client` in the inner forwarded. When would you ever forward a `jabber:server` or component message and who would care?

  113. Kev

    For non-specialist use, I don't think you would.

  114. pep.

    Zash, for when MUC has modified the message and thus is now no jabber:client anymore but :component :P

  115. nicoco

    but for on-join history it has to be: ``` <message type="groupchat" xmlns="jabber:component:accept"> <body> ``` no client at all here

  116. Kev

    Because every stanza you send to the server from your component is in :component. The server then rewrites to :server or :client as appropriate.

  117. nicoco

    I understand that the client will neven see this :component xmlns because the server will change it, but this is what slidge should send above, isn't it?

  118. nicoco

    again, all of this seems to be working, but I'd like to avoid things working just because clients are tolerant, since they may stop at any point =)

  119. Kev

    You'd typically put the xmlns on the stream element for jabber:component:accept, and then not include a namespace on the stanzas, but the end result is the same, yes.

  120. nicoco

    alright. thanks for your patience. in conclusion, my slixmpp hacks for what's inside forwarded were justified. good!

  121. pep.

    Kev, that's for the serializer to sort out, the applicative layer may require namespaces

  122. pep.

    In minidom (rust) we require that everything be namespaced for example, even though obviously we'll deduplicate where we can

  123. Zash

    Prosody also internally has no xmlns (or `nil`) on stanzas and rely on inheriting the namespace of the stream when sending them.

  124. Kev

    > In minidom (rust) we require that everything be namespaced for example, even though obviously we'll deduplicate where we can I know, I had to work around that issue just the other day.

  125. pep.


  126. pep.

    I think it's a feature :P

  127. Kev

    Disallowing documents without a root namespace.

  128. pep.


  129. Zash

    Explicit > Implicit, but muh convenience!

  130. pep.

    I have specifically added a new endpoint for this that you may like

  131. pep.


  132. Kev

    I'm not sure that helps me - it's not that my root was prefixed, it's that my root has no namespace.

  133. pep.

    Ah well

  134. pep.

    That's not a use-case for XMPP then

  135. Kev

    Not actually true, but it doesn't matter, I'm doing hacky string manipulation before feeding into the parser to workaround the issue.

  136. pep.

    Well if it were XMPP you'd have at least the None case with jabber:client or the like