jdev - 2024-03-25


  1. viyan

    @jonas' is there any other way to send this playerObj = {player: {0: 3, 1: 4, 4: 2}}. I want to send this stanza to xmpp dynamically

  2. viyan

    I don't want to send the data like in one <json></json>.

  3. jonas’

    then you'll have to consult your XMPP library's documentation on how to make a nice XML thing out of that

  4. jonas’

    can't help you there, I'm not a javascript person :)

  5. jonas’

    (others here may be, but I'm not; in any case, you should probably state which specific library you're using)

  6. Schimon

    goffi > Schimon: yes it's PEP (XEP-0163) singpolyma > Yes, any jid can have as many pubsub nodes as you like, so long as the server supports it > The protocol certainly supports it I figured I would make the bot to publish into PubSub service nodes of JIDs, and then I figured that this task should be a matter of each client to its own (i.e. a task of a messaging software). I concluded that it would be sensible to publish into its own PubSub node (specifically "urn:xmpp:microblog:0" which is utilized by Movim) and to PubSub services publish by the server the bot operates at, supposing it is permitted to do so as an administrator.

  7. Schimon

    goffi > Schimon: yes it's PEP (XEP-0163) singpolyma > Yes, any jid can have as many pubsub nodes as you like, so long as the server supports it > The protocol certainly supports it I figured I would make the bot to publish into PubSub service nodes of JIDs, and then I figured that this task should be a matter of each client to its own (i.e. a task of a client messaging and publishing software). I have concluded that it would be sensible for the bot to publish into its own PubSub node (specifically "urn:xmpp:microblog:0" which is utilized by Movim) and to PubSub services publish by the server the bot operates at, supposing it is permitted to do so as an administrator.

  8. Schimon

    goffi > Schimon: yes it's PEP (XEP-0163) singpolyma > Yes, any jid can have as many pubsub nodes as you like, so long as the server supports it > The protocol certainly supports it I figured I would make the bot to publish into PubSub service nodes of JIDs, and then I figured that this task should be a matter of each client to its own (i.e. a task of a client messaging and publishing software). I have concluded that it would be sensible for the bot to publish into its own PubSub node (specifically "urn:xmpp:microblog:0" which is utilized by Movim) and to PubSub services publish by the server the bot operates at, supposing it is permitted to do so as an administrator.

  9. lovetox

    i think i asked this a few days ago, does a marker id reference the original message, or the correction of the message?

  10. singpolyma

    Original

  11. singpolyma

    Nothing every references a correction id

  12. lovetox

    cheogram does not do that, are you aware?

  13. singpolyma

    Oh. Hmm. I was going by my nothing every references a correction id rule. But you're right in this case the answer might be ... Both?

  14. singpolyma

    I defer to Daniel on that. But I guess it makes sense to know if a particular correction has been displayed yed

  15. singpolyma

    I defer to Daniel on that. But I guess it makes sense to know if a particular correction has been displayed yet

  16. lovetox

    we probably have to differentiate, received and displayed

  17. lovetox

    for receiving, for me its more clear to always reference the message id which is incoming

  18. lovetox

    it does not matter what the content is of that message

  19. singpolyma

    Right. Delivery receipts are lower level you can send them for message stanzas with no body even or whatever

  20. lovetox

    hm but we probably could argue the same way for displayed i guess

  21. lovetox

    i think there is no really strong argument for one or the other

  22. lovetox

    we just should do all the same

  23. lovetox

    diplayed is for me code very near the GUI, so i have all infos there because i just displayed them to the user

  24. lovetox

    received markers, currently i catch even before processing the message into the database

  25. lovetox

    to say i need to reference the original .. could mean i need to make a db request .. or i simply trust the corrected id ..

  26. lovetox

    which i probably would do .. cant really hurt

  27. lovetox

    ah i think i dont care

  28. lovetox

    just need to know what to do ..

  29. singpolyma

    Yeah. I think I was wrong.

  30. lovetox

    but whats with reactions for example

  31. lovetox

    they should target the original? and then i change the content afterwards ?

  32. singpolyma

    Reactions, replies, etc are what I had in my mind. None of those every reference a correction id

  33. singpolyma

    Reactions, replies, etc are what I had in my mind. None of those ever reference a correction id

  34. lovetox

    i dont think that was a conscious decision

  35. lovetox

    it makes sense for both in my opinion to target a correction id

  36. lovetox

    both XEPs reference specific content, corrections change the content ...

  37. lovetox

    thats not so nice

  38. singpolyma

    If I reply to something and you edit it, should any synthetic quote in the UI show the edit? I think users would expect yes

  39. singpolyma

    Correction changes content but not the stanza id, so that's why I ref original id. That and I can't be sure everyone has seen the correction yet

  40. lovetox

    really? why would i not want to see what i actually replied to

  41. singpolyma

    Why would i want to preserve typos in one part of the UI? Wouldn't that just feel broken?

  42. lovetox

    you have chosen a very generous case there :D

  43. lovetox

    yeah we all think a typo does not matter, im with you, not sure this brings much further in finding out whats right

  44. lovetox

    also, stanza-id and message-id are the same in this case

  45. lovetox

    every correction has a new stanza-id as it has a new message-id, is what i mean

  46. lovetox

    i wonder now what other messengers do

  47. theTedd

    lovetox, consider: I send a message, then correct it, you reference it, then I make another correction - which message do you want to reference? Conceptually, they're all the same message, so it's cleaner to reference the first

  48. lovetox

    there is no right or wrong, no matter what way you choose, it will have pros and cons, it will be easy for one implementation, and hard for another

  49. lovetox

    for my implementation, its easy either way, because i store the full message correction as its own message in the database

  50. lovetox

    i can join any data with it that you send afterwards easily

  51. lovetox

    other implementations correct the message in the original database row, they dont store the message-id of the correction at all

  52. lovetox

    it will be very hard for them to deal with messages referencing correction ids

  53. theTedd

    Then there is always the possibility that a message id could be corrected away and the reference points nowhere; at least if it's always the first, that can be saved and depended on

  54. lovetox

    i didnt understand this, a message id can be corrected away?

  55. lovetox

    anyway, im not aware of any of the XEPs that reference messages, even mention it, we have already as pointed out implementations in the wild that defintily dont do it that way

  56. theTedd

    If some implementations don't store the original message-id, then a correction of that message will erase its id (replaced with another)

  57. lovetox

    i said "they dont store the message-id of the correction"

  58. theTedd

    Sorry, I just noticed that too

  59. theTedd

    So they only have the option of referencing the original id anyway

  60. lovetox

    yes, what i wanted to say is, its not a small thing, if you didnt plan for this at the beginning when writing your application, it can be, depending on the approach, very hard

  61. lovetox

    and none of the XEPs that reference messages existed even remotely when message correction was implemented by many clients

  62. theTedd

    Options: 1. reference the original message id, even with corrections - so a correction after the fact still points to the same message; 2. reference the latest corrected message id - which some clients don't track, and a later correction will also mess up the reference

  63. lovetox

    im with you, i feel referencing the original message is probably the easier thing, that most clients can deal with

  64. lovetox

    buuut as above pointed out, very prominent clients exactly dont do this, cheogram and Gajim only two i just checked

  65. theTedd

    Cheogram: "Correction changes content but not the stanza id, so that's why I ref original id."

  66. lovetox

    he meant, after thinking about it, thats probably what he would do. It currently refs always the latest message

  67. singpolyma

    lovetox: for replies and reactions?

  68. singpolyma

    it shouldn't but maybe we have a bug

  69. lovetox

    ah i didnt notice that that sentence was meant for reactions only

  70. singpolyma

    yeah, I didn't implement the displayed markers code so it does whatever conversations does. again, unless there's a bug

  71. singpolyma

    but always doing markers for latest probably makes sense

  72. lovetox

    but if we accept that it could be different from XEP to XEP, then its even more important to write it into every xep

  73. singpolyma

    vs replies, reactions, and corrections which I think should always ref the original id

  74. singpolyma

    yeah, I agree clarity in the xep is good

  75. theTedd

    If markers reference a correction to an earlier message, you're suggesting all already-read messages after have no been read (just to re-flag the modified message)

  76. lovetox

    thats a good point, i think the marker xep even says you should only mark forward

  77. lovetox

    so thats what i initially thought, its up for debate for every single XEP that references a message

  78. singpolyma

    yeah

  79. lovetox

    you need to think about if it makes sense for that particular xep to reference the original message or the correciton

  80. theTedd

    I don't see any good coming from referencing a replaceable correction-id

  81. lovetox

    you just named the display marker use case as an example ..

  82. singpolyma

    for anything other than markers

  83. singpolyma

    and receipts

  84. lovetox

    haha :D

  85. lovetox

    and i bet if we ask 5 people more we get a few more opinions on other XEPs as well

  86. lovetox

    as i said i think i can live with both, i have no strong feeling one or the other way

  87. theTedd

    If the id you reference can be replaced, your reference is meaningless; if you always reference the original (and everyone knows that happens) then it can be stored and handled (compared with tracking the history of all correction-ids just in case you need them)

  88. lovetox

    so you would need to store the original id and the last correction id anyway, otherwise you could not implement the display marker xep

  89. lovetox

    so it just about the in between messages

  90. lovetox

    or the question, do you store all corrections, or only the last one

  91. theTedd

    If a message has been displayed, and then it's corrected, has is still been displayed? Obviously the correction hasn't, but has 'the message' from the user's point of view?

  92. lovetox

    that question was what brought me to this channel today

  93. lovetox

    my plan was to reset the displayed state

  94. singpolyma

    that's a UI question, different apps may choose to differ there

  95. theTedd

    When there are messages after that one, it's going to be weird for the marker to jump back

  96. lovetox

    it does not jump back

  97. lovetox

    i only mark the last displayed message

  98. lovetox

    its you write something, i sent dispalyed, you correct it, do you not want to know if the correction was read?

  99. lovetox

    it could be important, like lets meet at 11.00 lets meet at 12.00

  100. lovetox

    ah yes i think i know what you mean

  101. lovetox

    what if you correct a message from an hour ago, then its hard to do with a "has read up to this point" line marker

  102. lovetox

    and anyway you cant really say with the displayed marker xep anyway

  103. lovetox

    because you could correct a message from an hour ago, then immediatly send a new one

  104. lovetox

    when the user reads, he will only send a displayed for the last one

  105. lovetox

    so you can never know if he actually read the correction

  106. theTedd

    So signaling corrections needs to be a separate indication

  107. lovetox

    so yeah that means .. display markers for corrections, in reality probably never matter much

  108. singpolyma

    unless it's the most recent message

  109. lovetox

    yeah thats that special case i had in mind

  110. lovetox

    but not sure if its worth to add all that extra thought into that one

  111. theTedd

    If the message is still in view, it doesn't matter too much, but indicating recently corrected messages is helpful

  112. lovetox

    yeah but thats another topic, more into the direction of notifications for corrections

  113. lovetox

    definitly want that, especially if you accept corrections for all messages

  114. lovetox

    and not only for the last one

  115. lovetox

    im out for tonight, sleep well

  116. theTedd

    adieu