jdev - 2023-06-11

  1. lovetox


  2. lovetox

    sounds like bittorrent

  3. pep.

    Yeah that looks like a cool feature :)

  4. pep.

    Maybe it could be made even cooler by being able to share chunks

  5. Zash

    just use bittorrent directly, then include a web seed pointing at the http uploaded file!

  6. pep.


  7. Zash

    http-upload the .torrent

  8. Zash


  9. lovetox

    > The Sender MUST NOT send a retraction request for a message with non-messaging payloads

  10. lovetox

    i read this now in 2 XEPs

  11. lovetox

    what is a non-messaging payload

  12. lovetox

    seems like open for interpretation

  13. Zash

    that interpretation should then be written down in https://xmpp.org/extensions/xep-0226.html

  14. lovetox

    is a XEP-0447 Payload, a messaging payload?

  15. Zash

    Does it end up as something in the message view in a client?

  16. lovetox

    i rather not interpret XEPs depending on GUI implementations

  17. lovetox

    i think this is a recipe for failure

  18. Zash

    Isn't that what it comes down to?

  19. Zash

    Is this some kind of message for meant for a user?

  20. lovetox

    i hope not, i didnt write these XEPs, no idea what they meant

  21. Zash

    Or, like, some system stuff

  22. lovetox

    the example for a non-messaging payload is a roster item exchange

  23. lovetox

    though its very thinkable, that a client shows a shared contact in the message view

  24. lovetox

    and gives the user a option to add this to his roster or ot

  25. lovetox

    and gives the user a option to add this to his roster or not

  26. lovetox

    if we interpret "messaging payload" as a message with a body intended to be read by the user (so not somekind of fallback body)

  27. lovetox

    this would exclude 0447, meaning you cant retract that, which seems also wrong, because if i share a photo, why should i not be able to retract that

  28. Zash

    lovetox, I did not mean you should read what xep-0226 says now, I mean that if a proper definition of "messaging payload" should be written down. Either in '226 or in a new XEP that replaces it.

  29. Zash

    lovetox, I did not mean you should read what xep-0226 says now, I mean that if we come up with a proper definition of "messaging payload" it should be written down. Either in '226 or in a new XEP that replaces it.

  30. lovetox

    and the correction XEP

  31. lovetox

    > Correction MUST only be used to change the logical content details of a stanza (e.g. the message body) and not to change the nature of the stanza or its metadata

  32. lovetox

    is a oob url and oob description, metadata

  33. lovetox

    is a oob url and oob description, metadata?

  34. singpolyma

    Yeah. "not change the nature of the stanza" makes sense "or it's metadata" is super meh imo

  35. singpolyma

    Is thread data or no? What about subject? What about oob or sims?

  36. singpolyma

    I allowed correcting thread for now

  37. Zash

    thread seems more metadata than data

  38. Zash

    and thus began the great XMPP meta vs data war!

  39. MSavoritias (fae,ve)

    hey i am writing my doap file and saw that in the xep the example has also releases. But its used only by xmpp.rs currently it seems. Is the releases planned to be used to give download links from the xmpp website?

  40. Zash

    I would prefer linking to the projects own download page

  41. Zash

    Tho with the data there, nothing stops you from building such a thing yourself :)

  42. MSavoritias (fae,ve)

    hmm. yeah makes sense. i will add it then. my main thinking was that the file may become to large

  43. MSavoritias (fae,ve)

    but then again i dont support that many xeps ^^'

  44. Zash

    DOAP isn't specific to XMPP after all

  45. pulkomandy

    talking about DOAP... https://xmpp.org/extensions/xep-0453.html has a dead link in section 5, the README was converted from .rst to .md it seems?

  46. MSavoritias (fae,ve)

    ah yeah. also the link in the first section is dead

  47. MSavoritias (fae,ve)

    > The information listed SHOULD include, but isn’t limited to, the project name, homepage, description, logo, screenshots if relevant, specifications supported (RFCs and XEPs). A full list of supported properties is described in RDF format at http://usefulinc.com/ns/doap#.

  48. MSavoritias (fae,ve)

    or its supposed to be and i am missing something

  49. MSavoritias (fae,ve)

    but from the wording it should work it seems

  50. Zash

    Turns out namespaces that resolve to their own schemas might not be the most reliable idea.

  51. lovetox

    i wonder why the replies XEP says one must add the jid of the one you reply to

  52. lovetox

    seems like added complexity, now i need to check if the jid matches the one who sent the replied to message

  53. lovetox

    ah, is this maybe for the case where you cant find the replied to message locally

  54. lovetox

    so then you can atleast attach a name to the reply when you use the fallback body?

  55. lovetox

    with all these new XEPs referencing messages, i think something like loading MAM messages backwards becomes very hard

  56. lovetox

    when you receive corrections / retractions / replies to messages you didnt see yet

  57. singpolyma

    Usually I load into the db and then UI sees it all forwards

  58. lovetox

    it actually doesnt matter how you request MAM, with these XEPs we need to be prepared to receive such messages, and the reference does not exist locally

  59. lovetox

    how do you deal with that?

  60. singpolyma

    Insert to the db with the reference ID, then do the join starting from messages so that stuff referencing messages that are not there doesn't get loaded for ui

  61. lovetox

    how do you insert a retraction? a retraction means you should delete a existing message or annote it with a flag that it is retracted

  62. singpolyma

    Yup, that's a good point, so probably should store it at an annotation same as a reaction or reply

  63. lovetox

    or simply dont allow requesting history backwards in MUCs, like Gajim does currently

  64. lovetox

    then you dont need to think about these problems

  65. lovetox

    i mean of course i can think about ways to make this work, but all mean multiple db queries per received message, instead of simply one insert

  66. lovetox

    i swear writing a XMPP client is a major software architecture project

  67. Zash

    > simply one insert this simplicity currently lives at the server. there's that whole thing about fastening that I imagine boils down to moving it to the client, so the server gets the complex end

  68. Zash

    complexity remains constant of course

  69. singpolyma

    Should still be one insert. then a join at load time

  70. Zash

    Sure, you can move the complexity from receiving to display :)

  71. singpolyma

    I wouldn't call a join complexity, but sure

  72. lovetox

    singpolyma, if it would be that easy, like recieve all data -> then display

  73. lovetox

    but the reality is, you receive data and need to display immediately

  74. Zash

    lovetox, if the join is easy, then the complex part was probably in designing the database schema? :)

  75. lovetox

    yes, i currently write a new database schema for gajim

  76. lovetox

    thats why i think about all that

  77. lovetox

    and i wonder which xmpp developer really thinks about all that at the start, probably none

  78. singpolyma

    > but the reality is, you receive data and need to display immediately I usually don't do that currently. Always goes into db, UI always loads from db

  79. lovetox

    hm interesting idea

  80. lovetox

    yeah i dont do this

  81. lovetox

    i insert into db, then pass data on to events to display it

  82. lovetox

    so no db load occurs anymore

  83. lovetox

    of course i could insert it, then load, this would have the added benefit that i dont have 2 data structures, one object loaded from db, and a second that represents some Message "Event"

  84. lovetox

    and then all the joins work nicely

  85. singpolyma

    Yeah, that's why we do it that way

  86. lissine

    re message replies, if the message being replied to isn't already in the db, you could use the fallback message (used for clients not yet supporting replies) to display the reply properly. And if the user clicks on the message being replied to, that should trigger fetching mam history from the server until the message is found

  87. singpolyma

    I guess in a big MUC you might not want to always load it all

  88. lovetox

    yeah reply does probably not break, also message corrections have a nice fallback

  89. lovetox

    retractions you need to save in a different table, and check at display time

  90. singpolyma

    Correction and retraction are semantically the same. Just a retraction you're always replacing with "nothing"

  91. lovetox

    is it? maybe if you dont store old corrected texts

  92. lovetox

    if i receive a correction without having the original, i can simply show the correction, its a normal message

  93. lovetox

    i guess its similiar, but in gajim we show the correct message history

  94. singpolyma

    Sure, you can show it, but it would be out of order time wise and also probably don't want to show the dupe after fetching the original later

  95. singpolyma

    So need to keep that association somehow

  96. lovetox

    currently when i store a message

  97. lovetox

    if i receive a correction, i dont store the message, i simply replace on the original message row, the text

  98. lovetox

    at the end i have only one database row, even if there were 20 corrections

  99. lovetox

    ( lets not think about storing correction history for now )

  100. lovetox

    now how would you do this when you receive the whole history the other way around

  101. lovetox

    you receive the last correction, do you store it into the db?

  102. lovetox

    but it is not the original message, and the next correction will not even reference this correction anymore

  103. lovetox

    or do you store all corrections in a different table, and dont dsiplay until you receive the original

  104. lovetox

    sounds more sane

  105. singpolyma

    Yeah, that's the easiest choice I expect

  106. lovetox


  107. singpolyma

    When getting correction with no original could insert a "fake original" to be replaced later when getting real original, but that's definitely not a clean one insert to do it that way

  108. lovetox

    hm im not really getting it, handling corrections backwards seems like a non trvial thing

  109. lovetox

    hm but this should work, if i put the corrections in a different table, and wait for the original ..

  110. lovetox

    i think i will try that, lets see