jdev - 2023-06-06

  1. lovetox

    Ofrom is necessary if you support MUC history , when I remember correctly

  2. lovetox

    If you only support MAM the it's not necessary

  3. lovetox

    the reason is that the only way for a MUC to make a real jid known is via presence

  4. lovetox

    problem is, if a user joins a muc and requests MUC history, the users that generated that history may not be joined anymore

  5. lovetox

    so how would the MUC make the real jid known

  6. lovetox

    in come XEP 0033

  7. lovetox

    when i think about it now, the same thing is probably true for a MAM history request anyway

  8. lovetox

    ah no MAM has its own mechanism to make the real jid known

  9. lovetox

    via <x xmlns='http://jabber.org/protocol/muc#user'> ✎

  10. lovetox

    via `<x xmlns='http://jabber.org/protocol/muc#user'>' ✏

  11. lovetox

    so i think i remember correctly, ofrom is necessary for all servers that offer MUC History, and all clients who implement MUC History

  12. lovetox

    on that note, i dont know why clients still bother with MUC History

  13. lovetox

    Gajim removed it since years

  14. MattJ

    Nice 🙂

  15. hari

    trollge dei mental ✎

  16. hari

    trollge dei paithiyam ✏

  17. MattJ

    hari, we've moved on from that incident. Can we help you?

  18. hari

    Hello MattJ can you explain how client and component connecting in xmpp?

  19. MattJ

    They both connect to the server. Client connections usually happen over a TCP+TLS stream or over websockets.

  20. MattJ

    Components usually connect to the server over a local connection from the same machine

  21. hari

    I have a component named `hari.abc.org` in xmpp server, how can i send a stanza as a anonymous user to that server component?

  22. MattJ

    <message to="hari.abc.org"><body>Hello world</body><message>

  23. MattJ

    to="anything@hari.abc.org" will also work

  24. hari

    How to send stanza from that server to that `anything@hari.abc.org` (client)?

  25. edhelas

    singpolyma so based on what lovetox said I'm not planning to merge that PR

  26. edhelas

    Also because it really change how the messages are handled and introduces a few DB requests that will slow things down

  27. MattJ

    hari: you said hari.abc.org is your component, so the client address must be something else

  28. MattJ

    When your component receives a stanza, it will have a 'from' address on the stanza, you just send your reply to that address

  29. hari

    Okay, thank you MattJ

  30. singpolyma

    edhelas: ok. I will have to prioritize a small fork probably then. Thanks for letting me know

  31. edhelas

    The performances with your patch will probably not be good at all, it add one, maybe two SQL requests for each messages received.

  32. singpolyma

    If that is the concern I'm certainly happy to try figuring out how to improve it

  33. singpolyma

    edhelas: the extra query is to load the contact associated with the message, right? That's the main offender?

  34. hari

    Hello MattJ ,it sends stanza to the server itself .No stanza sent to the client.

  35. MattJ

    What type of stanza?

  36. hari

    Message stanza

  37. MattJ

    Are you sending to a bare JID (user@example.org) or a full JID (user@example.org/resource)?

  38. hari

    full jid

  39. MattJ

    Then it should work fine, if the client is connected

  40. MattJ

    You are sending to exactly the same JID you received the message from?

  41. hari

    ` this.xmpp.on("stanza", async (data) => { const message = xml( "message", { type: "chat", from: "hari.abc.org", to: data.attrs.from }, xml("body", {}, "Hello People") ); await this.xmpp.send(message); } ` Like this

  42. techmetx11

    hari: i'm assuming the JSON object gets serialized to <message type="chat" from="hari.abc.org" to=[data.attrs.from]><body>Hello People</body></message>

  43. MattJ

    hari: you can enable debug logging (it looks like you are using xmpp.js? It has a debug mode you can enable), then you will see the exact XML sent/received

  44. MattJ

    If it looks correct, you should next investigate your server logs to see what happens next to the message

  45. lovetox

    about the <x> which was added for PMs. Is there any reason why the MUC Server can not add this tag ?

  46. Zash

    How does your server know it's a PM then?

  47. Zash

    Before it reaches the MUC

  48. lovetox

    ah because of MAM?

  49. lovetox

    yes its true that my server would not know it

  50. lovetox

    but this is no argument why the MUC server does not enforce that at least the other side knows it

  51. Zash

    Well it could if it kept track of MUC joins, which is possible but extra work.

  52. lovetox

    maybe i misunderstand how PMs work

  53. lovetox

    i thought PMs are sent "over" the MUC server

  54. Zash

    You → your server → MUC → recipients server → recipient

  55. lovetox

    its a chat message to a full jid

  56. Zash

    The MUC can't enforce things on the left side of tha

  57. Zash

    I don't see why it (and the XEP) couldn't enforce it on messages coming out tho.

  58. lovetox

    exactly and when i address a chat message with a full JID to a MUC server, what would it be other than a PM?

  59. lovetox

    ah

  60. lovetox

    i think i misunderstood your answer

  61. lovetox

    > Well it could if it kept track of MUC joins, which is possible but extra work.

  62. lovetox

    you meant my server

  63. lovetox

    obviously the MUC server keeps track

  64. Zash

    Sure

  65. Zash

    But I don't know if servers actively keep track of MUC joins

  66. lovetox

    i dont care about the left side

  67. Zash

    The minimum required is to keep track of directed presence.

  68. lovetox

    if a user uses a client who does not add the X, maybe this client does not need it, and has no use for it

  69. lovetox

    but that does not mean that others on the right side dont need it

  70. Zash

    MAM and Carbons could be confused, on both sides of the MUC

  71. lovetox

    sure, there are arguments for the sending client to add it, we dont need to discuss this

  72. lovetox

    but there are clients out there who will never get updated, because legacy

  73. lovetox

    Would it not be sensibel for the MUC server to add the <x> if it is missing, and the MUC server knows that its a PM

  74. Zash

    Yes, it would.

  75. lovetox

    thanks

  76. Zash

    Me, in 2014, apparently agreed as wel:: https://hg.prosody.im/0.10/rev/09151d26560a ✎

  77. Zash

    Me, in 2014, apparently agreed as well: https://hg.prosody.im/0.10/rev/09151d26560a ✏

  78. lovetox

    so you are saying prosody does this already

  79. Zash

    yes

  80. lovetox

    great, one of the list ✎

  81. lovetox

    great, one off the list ✏

  82. Zash

    But now I'm uncertain what happens if it's already there

  83. Zash

    Ah, been there, done that: https://issues.prosody.im/1427

  84. lovetox

    the whole occupant-id XEP is a bit optimistic isnt it

  85. lovetox

    > The occupant identifier MUST be generated such that it is stable. This means that if a user joins the same room a second time, the occupant identifier MUST be the same as was assigned the first time

  86. lovetox

    > One way to ensure these properties is to generate a private secret key

  87. lovetox

    so something that can be easily lost

  88. Zash

    Something like `HMAC(room.random, occupant.real_bare_jid)`

  89. Zash

    As easily lost as the room configuration 🤷️

  90. Zash

    In Prosody it's basically a hidden config option ✎

  91. Zash

    In Prosody the room secret is basically a hidden config option ✏

  92. lovetox

    so you are saying, if a server operator would lose this key

  93. lovetox

    no ..

  94. Zash

    > One way

  95. lovetox

    the problem is the client will never know if this key was lost

  96. Zash

    You could just as well be lazy and make the room JID the key

  97. lovetox

    even if the room config is lost, and all rooms are wiped, if they are recreated, the client will never know

  98. Zash

    Why do you need to know that?

  99. lovetox

    because then all my assumptions which i base on occupant-id are out of the window

  100. lovetox

    obviously we have it to identify persons across nick changes and in anonymous rooms

  101. lovetox

    how this could be solved in my opinion is, if a value is placed in the room disco info which is also generated by this key

  102. lovetox

    as long as this value does not change i know the server operator did not lose his key

  103. lovetox

    hmm but what if the key is lost and a new one is generated

  104. lovetox

    all occupant ids would then need to be different

  105. lovetox

    so probably not *that* bad

  106. lovetox

    the only bad thing would be if a occupant-id now points at another user

  107. lovetox

    which is hopefully nearly impossible

  108. lovetox

    the only place i would notice is, if real jids are visible

  109. lovetox

    if i plan ahead and simply assume that a real jid per groupchat can in the end have multiple occupant-ids

  110. lovetox

    i should be fine

  111. lovetox

    or i simply never try to match real jids with occupant-ids, then im just oblivious to the fact that it changed

  112. Zash

    if you have real jids, do you really need occupant-ids ever?

  113. lovetox

    no, but if you have both one could imagine methods like, get_contact_from_occupant_id()

  114. lovetox

    and that contact would have a real jid

  115. lovetox

    or something in that realm, hard to say for what we will need the occupant id in the future

  116. lovetox

    for now lets count what we can do with it

  117. lovetox

    retract a message, track nick name changes

  118. lovetox

    hm maybe im overthinking this

  119. lovetox

    no we dont need it for message retraction

  120. lovetox

    for what do i need the occupant-id ..

  121. lovetox

    ah indeed message retraction

  122. Zash

    for retractions and such that happens in the MAM logs

  123. lovetox

    ah because its not moderation

  124. Zash

    if you do not observe the event directly (with all the presence info)

  125. lovetox

    its user retractions

  126. Zash

    ah yeah

  127. Zash

    for moderation you might at most want to have a way to select the user even if they try to avoid you by changing nickname

  128. Zash

    e.g if you select a message and have an action to ban the user from there

  129. lovetox

    in the moderation case i have the real jid anyway

  130. Zash

    ah, right, most likely

  131. lovetox

    also in the lmc case i could check the occupant id

  132. lovetox

    last time we talked about some other xep that was beeing rewritten

  133. lovetox

    becasue it misses occupant id

  134. lovetox

    do you remember what that was?

  135. Zash

    LMC in MAM, or live correction of a message you got from MAM, that was the original use case, right?

  136. Zash

    dunno, check logs of here?

  137. lovetox

    search for the win

  138. lovetox

    it was Mentions

  139. lovetox

    of course in a anonymous room you want to use something more stable then the nick

  140. Zash

    hm, yeah

  141. Zash

    occupant-id really should have been the resource slot instead of nickname :/

  142. Zash

    do moderators always have the real jid?

  143. lovetox

    admins at least

  144. lovetox

    not sure about moderators

  145. Zash

    If you could use occupant-id for administrative actions, then there's less need for them to see real JIDs

  146. lovetox

    moderators can see the real jid

  147. lovetox

    > but MUST include the new occupant's full JID only in the presence notifications it sends to occupants with a role of "moderator" and not to non-moderator occupants.

  148. lovetox

    the problem is the member list, you will always need the real jid for that

  149. lovetox

    so not worth it to hide it for other tasks ..

  150. Zash

    perhaps we should invent a new way to get the member list, with a single command instead of one per affiliation

  151. Zash

    IIRC there's been wishes for that before

  152. Peter Waher

    I think JID forwarding is a configurable property of a MUC room, no?

  153. Peter Waher

    cf. muc#roomconfig_whois

  154. lovetox

    yes it is, but fyi this does not apply to all occupants

  155. lovetox

    only to ones with specific affiliations ✎

  156. lovetox

    only to ones with specific roles ✏

  157. lovetox

    e.g. admins/owners/moderators can always see your JID

  158. Peter Waher

    you can set muc#roomconfig_whois to anyone, to allow anyone™ to receive the same info (if that is of interest, for instance, for cybersecurity reasons)

  159. lovetox

    yes, we talk about the cases where people explicitly not do this

  160. lovetox

    maintaining certain features without having a stable identifier is tricky

  161. lovetox

    thats why occupant-id was invented

  162. Peter Waher

    (as there is no way to enforce adherence to nick-name-policies, and it is easy to pretend to be some-one else)

  163. Zash

    Peter Waher, let me tell you about https://xmpp.org/extensions/xep-0045.html#register

  164. lovetox

    acutally why was user retraction not made with MUC support

  165. Zash

    and https://xmpp.org/extensions/xep-0045.html#reservednick

  166. lovetox

    meaning, the MUC validates if a retraction comes from the right user

  167. lovetox

    and only forwards the retraction if it is

  168. Zash

    lovetox, because then all the MUC implementations must implement it?

  169. Zash

    and nobody can use it until then

  170. Zash

    nothing prevents that enforcement from being added, does it?

  171. lovetox

    so now all servers need implement occupant id, and nobody can use it till then

  172. Zash

    occupant-id is pretty easy tho, and useful for many things

  173. lovetox

    not true in a non-anon case we can already use it

  174. pep.

    "Zash> if you have real jids, do you really need occupant-ids ever?" Yeah, not to have 36 ways to do the same thing

  175. Zash

    2 == 36? ok

  176. MattJ

    Zash [21:55]: > perhaps we should invent a new way to get the member list, with a single command instead of one per affiliation https://xmpp.org/extensions/xep-0463.html

  177. pep.

    "Zash> If you could use occupant-id for administrative actions, then there's less need for them to see real JIDs" < this.

  178. Zash

    you're mixing hypothetical future possibilities with current states

  179. Zash

    > If

  180. pep.

    I was just reading logs and replying to that without reading the live feed

  181. pep.

    You're misinterpreting :)

  182. pep.

    s/this/I want this too/

  183. Zash

    Mixing threads is confusing without threading ;)

  184. Zash

    MattJ, there are too many XEPs!!!!1!!eleventy. I didn't know this one returned the initial state.

  185. pep.

    I know services where it's not possible to start a thread on a threaded message, so this certainly would have been useless :P

  186. pep.

    I wonder if affiliations results should contain the occupant-id too

  187. lovetox

    i would not open that box

  188. pep.

    Why not

  189. lovetox

    as said, the XEP says "MUST provide a stable-id"

  190. lovetox

    but we know because we are humans, that this will not be possible always

  191. pep.

    So we deal with it and it's fine?

  192. lovetox

    you could plan for it, but if you dont really have a use case

  193. pep.

    Wait what's "it" here?

  194. lovetox

    mapping jids to occupant ids

  195. lovetox

    whats nicer with occupant ids is, that there are included in messages

  196. lovetox

    not like real jids, where you need to map nicknames, to precenses

  197. lovetox

    and find the real jid that way

  198. pep.

    Yeah fwiw I think the resource was a mistake

  199. lovetox

    i guess everybody knows that, but nothing we can do about it now

  200. pep.

    We can progressively replace it :)

  201. pep.

    It's not like MUC stopped evolving

  202. MSavoritias (fae,ve)

    That would be nice. For stuff to evolve :D

  203. Zash

    Evolve or die (and be replaced by MIX)!

  204. MSavoritias (fae,ve)

    Heh. I can be behied that :P ✎

  205. MSavoritias (fae,ve)

    Heh. I can get behind that :P ✏

  206. pep.

    meh

  207. Zash

    Or we could do Groupchat 3.0!

  208. MSavoritias (fae,ve)

    MUX? MAX? MUC reloaded?

  209. lovetox

    did someone implement MIX and found something bad designed?

  210. lovetox

    for me cost/benefit is still not there

  211. lovetox

    there is some pains with MUC, but there are not that bad that i implement a whole new protocol

  212. singpolyma

    Yeah, I think it's not "bad" so much as it's very complex and not backwards compatible with few advantages

  213. lovetox

    its probably better designed, but for the enduser very little changes probably

  214. lovetox

    does prosody have some MIX support?

  215. Zash

    Not that I know of.

  216. singpolyma

    Just minimix heh

  217. MSavoritias (fae,ve)

    We have been too busy fixing other stuff to think about MIX and MUC anyway

  218. Zash

    and so much OAuth 2.0

  219. MSavoritias (fae,ve)

    Yep. But from what i have read at some point either MUC will need some serious revisit or MIX will need to be fixed/implemented

  220. Zash

    The main architectural thing is that in MUC, it is clients that join the chat, while in MIX it is the user, thus it doesn't matter if the client goes offline or stuff. But we can sorta emulate that with affiliations and addons, plus we already have MUC implemented and deployed.

  221. lovetox

    does MIX allow the 20.000 user room use case?

  222. singpolyma

    lovetox: that use case the only issue is presence really, right?

  223. Zash

    With 20 people actually active?

  224. lovetox

    singpolyma, yes

  225. Zash

    Presence is optional in MIX (and MUC) so presumably yes.

  226. singpolyma

    I've seen some say they fix that by disabling presence in big mucs

  227. Zash

    But can a human being really keep track of that many people? IIRC Dunbar says we can remember about 3000 people.

  228. lovetox

    i dont need to know who is in the room

  229. lovetox

    question is if some things break down if i have no presence at all

  230. lovetox

    i guess not if all messages have a occupant-id ^^

  231. Zash

    20.000 participants you neither see nor hear from? That's probably fien. ✎

  232. Zash

    20.000 participants you neither see nor hear from? That's probably fine :) ✏

  233. Zash

    At that point why not just poll MAM ?

  234. Zash

    Then you can skip the entering part

  235. Zash

    and all the parts

  236. lovetox

    for example currently a admin could not ban a user if presence is disabled

  237. Zash

    IIRC there was an idea for optimization where you only send presence if someone says sometihng

  238. Zash

    Then if someone says some shit, admins get presence and can use that to kickban

  239. lovetox

    also you can have no avatars

  240. lovetox

    but i guess MUCs could inject some kind of avatar hash into each message

  241. singpolyma

    Send presence before you send a message

  242. Zash

    Yeah

  243. lovetox

    i mean we could work around all those issues, and at the end we would probably land at something like MIX :D

  244. Zash

    And then we can add MIX the protocol on top of that MUC codebase!

  245. Zash

    And then phase out the MUC protocol bits

  246. singpolyma

    Current MUC avatars only barely work anyway and rely on stuff we'd like to deprecate (like vcard-temp)

  247. Zash

    After that any from-scratch implementation could be MIX from the start

  248. Zash

    singpolyma, so much this

  249. singpolyma

    Should do a new protocol that just uses pubsub ;)

  250. Zash

    load mod_pep onto the MUC, ???, PROFIT!

  251. Zash

    (srsly, if someone wrote some glue to hook up permissions with the MUC, then it should mostly work)

  252. singpolyma

    Zash: oh, I meant if we want to replace muc with something. PEP on the muc I want but that's not useful for avatars really

  253. MSavoritias (fae,ve)

    Yep. I am starting to mess around with a xmpp library myself and the choice was basically: MUC with a bunch of workarounds that make into MIX. Or MIX.

  254. Zash

    singpolyma, each MUC room gets a pubsub service, users could publish avatars there (% permissions)

  255. singpolyma

    Zash: gross

  256. Zash

    and then you could get away from the presence and vcard-temp requirements

  257. Zash

    singpolyma, why? it'd be kinda half-way to MIX

  258. singpolyma

    We can already do pep avatar with muc iq. We "just" need a way to advertise it

  259. Zash

    That requires an occupant and presence

  260. singpolyma

    I don't want to upload my avatar to every muc I join and have them all store it. Easy to get out of sync and very redundant

  261. singpolyma

    Zash: why presence?

  262. singpolyma

    I can do muc iq without presence

  263. lovetox

    i think this is already solved in prosody or not?

  264. Zash

    singpolyma, if you are offline, iq routing does not work

  265. Zash

    even the subset that gets redirected to the bare JID (which is an undocumented hack)

  266. singpolyma

    You mean not joined to muc? Sure, of course

  267. Zash

    could work if your nick was registered I guess

  268. Zash

    and needing a client to be joined is the big weakness of MUC

  269. singpolyma

    What is the undocumented hack btw? Based on namespace?

  270. Zash

    Yes

  271. Zash

    if namespace == vcard-temp then stanza.attr.to = barejid

  272. Zash

    IIRC ejabberd did it by handling vcard-temp to full JIDs :/

  273. singpolyma

    Makes sense. MUC iq is gross for sure. But it works well enough for this kind of thing. Unlike Muji where it's totally broken

  274. lovetox

    and if on the other hand is a server which does avatar conversion, then the request goes to your PEP or not?

  275. lovetox

    so in a way you can already request participants PEP in the MUC

  276. singpolyma

    > and needing a client to be joined is the big weakness of MUC Depends on use case I guess. It's also r big strength ✎ ↺

  277. singpolyma

    > and needing a client to be joined is the big weakness of MUC Depends on use case I guess. It's also a big strength ✏ ↺

  278. Zash

    s/weakness/trade-off/ wrt MIX

  279. singpolyma

    Sure. You really want to see who is currently in the group though, especially with small groups. And big public rooms you don't want to hang around to everyone you've ever seen.

  280. Zash

    Either could be done either way, with various differences and something something

  281. Zash

    Don't you use affiliations anyway?

  282. singpolyma

    For which part? I use affiliations for some stuff yes

  283. singpolyma

    Here's a question: does it *ever* makes sense to route a MUC iq to full jid? What's the use case that would actually work for? BoB maybe, anything else?

  284. singpolyma

    (i know Muji is using it, but it pretty much doesn't work there...)

  285. Zash

    singpolyma, disco#info, version query, dunno

  286. Zash

    probably mostly things that are privacy nightmares

  287. singpolyma

    I guess it's semi fine for those. There are cases where it'll break but maybe not in ways that matter

  288. lovetox

    hey i have a nice addition for MUC Moderation XEP

  289. lovetox

    add request to delete all messages from a user with a certain occupant id

  290. singpolyma

    can do that in the client pretty easily, no?

  291. lovetox

    no

  292. lovetox

    also not a reason to do it there only because you *can*

  293. lovetox

    the server can do it better and with much less stanzas

  294. lovetox

    you can only moderate what you saw as a client

  295. lovetox

    (which granted will be enough most of the the time)

  296. lovetox

    but it may not be all

  297. lovetox

    further i think its not the nicest thing to send for example 100 retraction stanzas at once

  298. lovetox

    uhh thinking about LMC retraction is probably tricky

  299. lovetox

    if a message was corrected 3 times

  300. lovetox

    and i didnt store all 3 ids

  301. lovetox

    a retraction can have unwanted consequences

  302. Zash

    retraction of the middle LMC?

  303. lovetox

    no of the last for example

  304. Zash

    thanks for the fresh nightmare material! :)

  305. lovetox

    usually the user want to remove the message that he sees

  306. lovetox

    but i think clients dont store the old corrected message ids anymore

  307. lovetox

    hmm ... maybe i should not allow in Gajim to retract corrected messages

  308. lovetox

    or think about it a bit more

  309. lovetox

    in MUC i think you are save if the server replaces with a tombstone that only removes the body?

  310. lovetox

    or maybe this is simply something the receiving client has to take correctly care of