jdev - 2023-06-08

  1. hari

    this.xmpp.on("stanza", async (data) => { console.log("Hey we're online! \t", data.attrs); const message = xml( "message", { type: "chat", from: "hari.abc.org", to: data.attrs.from }, xml("body", {}, "Hello People") ); console.log(message.attrs, "attr"); await this.xmpp.send(message); });

  2. hari

    MattJ why its continuously sending stanza in the server

  3. hari

    <message type="chat" from="hari.abc.org" to="hari.abc.org"><body>Hello People</body></message> Like this continuously

  4. Zash

    `to` equals `from` ?

  5. Zash

    Is it sending itself a message and then replying to it, in a loop?

  6. MattJ

    hari: maybe log what data it is replying to, it seems to be replying to itself

  7. nicoco

    Are there MUC components that force you to use the same nickname if you join a room with different clients and is there a related XEP for this? I have a vague idea that this was a thing but my ddging skills are failing me

  8. MattJ

    I'm not aware of any XEP. As for implementations, it seems like something an IRC gateway might do, but I'm not sure if biboumi does.

  9. MattJ

    When I say there's no XEP, I mean there's no XEP beyond XEP-0045 - which allows the service to force a nick, and also allows nick discovery.

  10. Kev

    XEP-0045 gives you the protocol for forcing nicks on people

  11. MattJ

    Just don't ask me which clients support these things :)

  12. nicoco

    thanks! some gateways (including slidge) definitely do that but I wondered if this behaviour existed outside of a gateway context. it's been working fine on most clients I use (dino, gajim, cheogram) and apparently soon™ in beagle too, cf https://github.com/tigase/beagle-im/issues/138

  13. Zash

    Prosody supports forcing use of registered nicknames

  14. Zash

    Might be a service-wide opt-in setting tho?

  15. hari

    MattJ `from` here is our component only , it loops and send stanza to itself

  16. MattJ

    `if(data.attr.from == "hari.abc.org") { don't send stanza }` :)

  17. MattJ

    But I'm still curious what stanza it is

  18. hari

    if (data.attrs.from != "hari.abc.org") { try { await this.xmpp.send(message); } catch (err) { console.log(err, "error"); } } I tried this .

  19. MattJ

    Looks good

  20. hari

    And then ,how to create muc using xmpp.js in client ?

  21. MattJ

    You send this to the address of the MUC you want to create: https://xmpp.org/extensions/xep-0045.html#example-153

  22. MattJ

    If this is a client (not a component) don't set 'from' here, just 'to'

  23. Zash

    I would recommend that you look trough the library docs for e.g. a MUC join function

  24. MattJ

    xmpp.js doesn't have a high-level MUC API, unfortunately

  25. nicoco

    > Prosody supports forcing use of registered nicknames Zash: thanks! interesting to know.

  26. lovetox

    consider the following scenario, one device joins a MUC, writes 3 messages, changes his nickname

  27. lovetox

    second device joins this MUC, requests MAM receives the 3 messages

  28. lovetox

    am i right to assume there is no way for the second client to ever detect that these 3 messages were sent by "us"

  29. singpolyma

    Indeed

  30. singpolyma

    Here's a worse one. Someone join with nick X and send 3 messages. They leave. Totally different person joins now with nick X. They get MUC history. No way to tell they didn't send the messages themselves...

  31. singpolyma

    Could say you are allowed to see your own jid, but this is not done today I think

  32. lovetox

    occupant-id also solves this i guess

  33. singpolyma

    Or non anon. Saying you can see your own jid actually makes sense I think, I dunno

  34. lovetox

    it would, question is does the server even store it

  35. lovetox

    is there a reason for the server to store the real jid beside each message, in a anon room

  36. singpolyma

    Moderation

  37. singpolyma

    To be able to see who it was and ban

  38. lovetox

    ? i think you misunderstand me, your suggestion was to attach the real jid to MAM results, if the message is from "you"

  39. lovetox

    i said this can only be happen if the server even stores that information

  40. singpolyma

    Right. I'm giving another use case for the server to store this

  41. lovetox

    i dont see any moderation task that needs a real jid saved to MAM

  42. lovetox

    banning kicking, has nothing to do with messages

  43. singpolyma

    Join room I moderate, see spam, how do I know who to ban if they left?

  44. singpolyma

    Need their jid somehow

  45. lovetox

    i forgot, the server needs to store it anyway

  46. lovetox

    because it needs to attach it at least to mam queries of Admins who always can see the jid

  47. lovetox

    so this information needs always be present i guess

  48. singpolyma

    Yes

  49. lovetox

    but yeah, occupant-id solves this also, no need to invent something additional

  50. lovetox

    i guess i have to live with sometimes simply not beeing able to determine that a message was sent by another device of mine

  51. pep.

    > Could say you are allowed to see your own jid, but this is not done today I think This is done in some impls I think

  52. pep.

    At least I'm doing it in my own implementation based on recommendations of other servers, (or rather, "prosody")

  53. MattJ

    That only helps if they are still online though, right?

  54. MattJ

    It seems to me that only occupant-id, plus storing that in MAM, is a solution here

  55. MattJ

    Obviously not for the retrospective ban or whatever

  56. MattJ

    But maybe we can define a way to perform admin actions on occupant ids

  57. singpolyma

    > That only helps if they are still online though, right? No, the idea is to put true jid in history/mam result ↺

  58. Zash looks at MAM results

  59. Zash sees `<occupant-id xmlns="urn:xmpp:occupant-id:0" id="DQtF4ZYfA81+iAg5zQ46PyK2p/1O4V577dcmlHrAsLE="/>`

  60. singpolyma

    Yeah. IIRC true jid is also there when allowed. I didn't think we're proposing a new idea

  61. pep.

    MattJ, I've planned to investigate about https://logs.xmpp.org/xsf/2023-01-05?p=h#2023-01-05-fe0286ff34b3de39 "A MUC could pretend to be non-anon and give out burner JIDs at a companion service" to have something that can be used in admins actions (because it's a JID) ✎

  62. pep.

    MattJ, I'm planning to investigate about https://logs.xmpp.org/xsf/2023-01-05?p=h#2023-01-05-fe0286ff34b3de39 "A MUC could pretend to be non-anon and give out burner JIDs at a companion service" to have something that can be used in admins actions (because it's a JID) ✏

  63. Zash tracks down https://hg.prosody.im/prosody-modules/rev/391c508e0b75

  64. pep.

    Also that could be the end of public rooms, by using MUC-issued aliases and making everything public :P ✎

  65. pep.

    Also that could be the end of non-anon rooms, by using MUC-issued aliases and making everything public :P ✏

  66. singpolyma

    You mean of semi Anon rooms? ✎

  67. pep.

    singpolyma, they would be de-facto anon

  68. singpolyma

    ✏

  69. singpolyma

    Right

  70. singpolyma

    I've considered running some in a new class "members can see JIDs"

  71. lovetox

    Not sure what problem you are talking about. Admins always see jids, and hence can do moderator actions

  72. singpolyma

    So you don't have the spam harvesting problems as much but it's mostly non anon

  73. Zash

    Hm, so we store real JIDs in MAM in whois=anyone rooms. Should that be done in all, but filtered so only mods can see?

  74. pep.

    mods or self?

  75. Zash

    Rules should be the same as if you were there and saw it live.

  76. singpolyma

    Yes

  77. Zash

    Gets weird with configuration changes tho

  78. singpolyma

    You mean because a re-fetch might see more/less data? That seems fine

  79. Zash

    No, I mean that if the room was whois≠anyone at the time you wrote a message, and later it changes to whois=anyone, it's weird to retroactively publish your JID

  80. Zash

    Anyway, "if you could have seen it live, you should see it in MAM" seems a sensible general rule ✎

  81. Zash

    Anyway, "if you could have seen it live, you ~should~ may see it in MAM" seems a sensible general rule ✏

  82. lovetox

    Still don't know what you all are talking about, this all already works like forever

  83. lovetox

    Otherwise omemo would not work

  84. pep.

    Because one generally uses OMEMO in non-anon rooms

  85. singpolyma

    I'm just talking about added "self" to the list of can see

  86. singpolyma

    pep.: also truu

  87. lovetox

    There is no anon room in xmpp

  88. lovetox

    There is a semi anon room

  89. lovetox

    Which means you ommot info for some users ✎

  90. singpolyma

    Yes, but you don't use omemo with semi anon

  91. pep.

    And non-anon. Even though I agree the term is weird

  92. lovetox

    Which means you omit info for some users ✏

  93. pep.

    But "public" is already taken

  94. Zash

    Since there is no true anon room, we could assume semi-anon and anon are synonymous

  95. lovetox

    The point is admin can see jids always

  96. lovetox

    So this info is already present in mam storage

  97. singpolyma

    Is or should be yes

  98. lovetox

    > Hm, so we store real JIDs in MAM in whois=anyone rooms. Should that be done in all, but filtered so only mods can see? This sentence makes it seem the info is not stored

  99. Zash

    In Prosody, it is not.

  100. jonas’

    Guus, in case you didn't see, the aioxmpp bug turned out to, indeed, be a bug in python 3.11.3, so you can now un-pin your python version (3.11.4 was released earlier this week)

  101. Guus

    jonas’: thanks, I was already planning to give it a go.

  102. Guus

    jonas’: no joy. Probably waiting for a GitHub action to be updated.

  103. moparisthebest

    jonas’: what was the bug? I'm curious