jdev - 2023-09-02


  1. edhelas

    Are some of you interested to implement https://xmpp.org/extensions/xep-0466.html ?

  2. edhelas

    Seems not that complex

  3. opal

    >An ephemeral message is a <message/> including an <ephemeral/> tag in the urn:xmpp:ephemeral:0 namespace, with an attribute timer (xs:unsignedInt) indicating the delay in seconds, after which a message MUST be discarded. rebuttal: other people MUST NOT be able to tell me which messages i SHOULD keep

  4. opal

    this is one of the shittier features other IM platforms introduced

  5. opal

    this xep also uses the obsolescent "negociation" lol

  6. MSavoritias (fae,ve)

    it would be nice to be implemented

  7. MSavoritias (fae,ve)

    and i definetily look to have this in my client

  8. edhelas

    Yes, for Movim it would be a nice addon :)

  9. MSavoritias (fae,ve)

    yeah its one of the things i am missing the most in xmpp

  10. singpolyma

    Why send with a timer instead of sending, running a timer, and retracting?

  11. lovetox

    Because for retracting you need to be online

  12. moparisthebest

    > Because for retracting you need to be online Maybe we just need server support for delayed sends instead

  13. moparisthebest

    ie send this message in X seconds

  14. cal0pteryx

    Also: retract this message in X seconds

  15. moparisthebest

    That's built in right?

  16. MSavoritias (fae,ve)

    why need server support like this?

  17. moparisthebest

    Then only your client would need to implement it, not everyone else's, plus it gives other features for free?

  18. MSavoritias (fae,ve)

    but it would suggest that the server needs to implement it. which makes it 1. unusable for p2p. 2. it would mean that the server can decide if they support it instead of giving agency to the people using the clients

  19. MSavoritias (fae,ve)

    plus of course not everything needs to be a server feature if it can be solved more simply

  20. moparisthebest

    This also gets you the delayed send messages that other platforms have, that it can be used for delayed retractions is an added bonus

  21. Zash

    Doesn't https://xmpp.org/extensions/xep-0079.html have delayed delivery?

  22. lovetox

    of course one could do this that way, but it sounds more complicated with a lot of edge chases

  23. lovetox

    instead of simply communicating everything to the other client with one simple message

  24. MSavoritias (fae,ve)

    yep

  25. moparisthebest

    > Doesn't https://xmpp.org/extensions/xep-0079.html have delayed delivery? Indeed, nice https://xmpp.org/extensions/xep-0079.html#conditions-def-deliver

  26. singpolyma

    It's needing server feature vs needing client feature. You need either a feature on your server is a feature on all remote clients. Which is simpler to achieve probably varies by user

  27. MSavoritias (fae,ve)

    why hasnt been implemented though? the 0079 that is

  28. Zash

    I don't think so, not by the current generation of software

  29. MSavoritias (fae,ve)

    because i know there is also fastening that seems to be doing something similar to reactions but we opted for a xep specific to reactions

  30. singpolyma

    AFAIK fastening is over. I didn't dislike the model but it had too little value for most to support I guess

  31. singpolyma

    That's the impression I got at summit

  32. Zash

    Case of premature genericness?

  33. MSavoritias (fae,ve)

    so maybe same thing with 0079?

  34. singpolyma

    Zash: premature of just underappreciated depending on PoV I guess

  35. singpolyma

    Zash: premature or just underappreciated depending on PoV I guess

  36. Zash

    MSavoritias (fae,ve), I think it was implemented in older servers, but fell out of fashion for its complexity and lack of use.

  37. Zash

    or did they just advance things to Stable without implementations back in 2005?

  38. singpolyma

    Don't we still?

  39. singpolyma

    I've never got the impression that most xeps have any implemetations

  40. Zash

    Final being the one that actually requires implementations

  41. moparisthebest

    I swear stable required 2 implementations

  42. Zash

    It was called Draft back then :)

  43. Zash

    > In order for a XEP to advance from Stable status to Final status [...] at least two implementations of the XEP must exist

  44. singpolyma

    Oh so we do have the ietf rule in there.... Just super late in the process and almost no xep gets that far

  45. moparisthebest

    Unclear why anyone would want to push a xep to final so no changes can ever be made

  46. MSavoritias (fae,ve)

    yeah. and a lot of xeps that are actually supposed to be implemented or are are obsolete

  47. MSavoritias (fae,ve)

    also that yeah

  48. moparisthebest

    Seems like a state that shouldn't exist

  49. moparisthebest

    Stable is good

  50. MSavoritias (fae,ve)

    yeah

  51. singpolyma

    > Unclear why anyone would want to push a xep to final so no changes can ever be made So that people can actually rely on it

  52. MSavoritias (fae,ve)

    and it should be easier to release new drafts

  53. singpolyma

    Instead we have something horrifying called "namespace versioning"

  54. MSavoritias (fae,ve)

    why is it scary?

  55. Zash

    And we often have implementations of Experimental :)

  56. singpolyma

    Once a xep goes to final you can update it, you just need a new xep number

  57. MSavoritias (fae,ve)

    isnt it supposed to be like that?

  58. Zash

    Things have drifted out of sync a bit

  59. MSavoritias (fae,ve)

    with namespaces

  60. singpolyma

    MSavoritias (fae,ve): every time the namespace changes it makes implemetations even harder

  61. moparisthebest

    > Once a xep goes to final you can update it, you just need a new xep number This isn't the ietf

  62. Zash

    singpolyma, that may have been the original intent, since RFCs work like that, but we don't seem to follow that anymore

  63. moparisthebest

    I agree namespace bumps should be avoided whenever possible

  64. sagaracharya

    How do I add luaevent if my distro doesn't have it packaged?

  65. sagaracharya

    To prosody

  66. singpolyma

    moparisthebest: correct, the ietf is better

  67. Zash

    > Once a xep goes to final you can update it, you just need a new xep number a council vote actually :)

  68. MSavoritias (fae,ve)

    > MSavoritias (fae,ve): every time the namespace changes it makes implemetations even harder why? you mean because you need to send to different namespace versions?

  69. singpolyma

    MSavoritias (fae,ve): you have to look for all versions on incoming and either pick one for outgoing or disco somehow

  70. singpolyma

    When the schema is fundamentally different you might need this anyway so I understand the mechanism

  71. singpolyma

    But most namespace bumps are like "added a new attribute" or "made this attribute optional"

  72. MSavoritias (fae,ve)

    > How do I add luaevent if my distro doesn't have it packaged? xmpp:prosody@conference.prosody.im?join

  73. MSavoritias (fae,ve)

    > But most namespace bumps are like "added a new attribute" or "made this attribute optional" well thats a different argument. i agree it shouldnt be taken lightly. but thats up to the council to vote it in no?

  74. sagaracharya

    I'm banned from it because jonas and MattJ were unable to answer for their misdeeds publicly

  75. sagaracharya

    MattJ unable to answer, I challenged him to explain.

  76. sagaracharya

    After 6-7 messages and no reply, I abused the bastard

  77. sagaracharya

    And thus, got banned

  78. wgreenhouse

    sagaracharya: sounds like someone we should be really invested in helping with their problem. /s

  79. MSavoritias (fae,ve)

    i think we all agree that the xep process needs changes anyway though

  80. singpolyma

    I mean, it doesn't need to work the way I would have it work 🤷‍♂️

  81. singpolyma

    But definitely I release working code before I even think to draft a spec

  82. MSavoritias (fae,ve)

    me too.

  83. MSavoritias (fae,ve)

    i mean how else you would know it works? right?

  84. Martin

    > After 6-7 messages and no reply, I abused the bastard If you continue using this type of language I guess you'll be banned here as well soon.

  85. sagaracharya

    Martin: Well, I know how things are going to proceed with MattJ being the owner

  86. sagaracharya

    Facelessness over internet is not solvable

  87. Trung

    > Are some of you interested to implement https://xmpp.org/extensions/xep-0466.html ? > > Seems not that complex Mission Impossible 😉

  88. Trung

    https://www.youtube.com/watch?v=KlyLtJd-ArY

  89. MSavoritias (fae,ve)

    snarky comments dont help though 🙂

  90. sagaracharya

    > snarky comments dont help though 🙂 🙂. So don't post snarky comments then.

  91. Trung

    I thought visualisation is necessary for certain people as they find it difficult to prefix `torsocks` to "hide" their IP. Not a fan of deleting messages but I'd get behind xep0466 tho. Pretty cool.

  92. jonas’

    sagaracharya, hi and welcome. I trust since you have returned that you'll now stick to the XSF CoC.

  93. MSavoritias (fae,ve)

    sagaracharya: it was a response to Trung not you

  94. moparisthebest

    > But definitely I release working code before I even think to draft a spec I agree, not everyone works that way but it seems to produce better specs in my opinion

  95. Zash

    Chicken vs egg all over again :)

  96. sagaracharya

    > sagaracharya, hi and welcome. I trust since you have returned that you'll now stick to the XSF CoC. jonas I have better things to do than talk to you.

  97. singpolyma

    sagaracharya: please refrain from this kind of a use in our channels, thanks

  98. sagaracharya

    Ok, I'll resolve it with MattJ first, if he's willing to answer

  99. moparisthebest

    Or just let it go and be happy

  100. moparisthebest

    I feel like when you do spec first it's the edge cases that get missed

  101. sagaracharya

    moparisthebest: Or MattJ can apologize and get even, and never use jonas to press people in this group and remove them when they fight back

  102. moparisthebest

    sagaracharya: just stop and be happy

  103. sagaracharya

    MattJ: Read the above and answer

  104. Zash

    moparisthebest, I suspect that implementation first has different issues. E.g. you might encode _your_ specific use cases, but miss others.

  105. moparisthebest

    Zash: so it protects against premature generalization? :D I'm sold

  106. Zash

    In the end, some middle way might be best, i.e. write a PoC and document what it did, then submit as Experimental :)

  107. singpolyma

    Zash: yeah, I think getting real user feedback is useful, but then once you have enough go to experimental and expect more changes when a second or third implemetation hrppens

  108. soulcaramel

    Hi everyone, does anyone here know of a client that lets you decide how many of the most recent messages to fetch? Is that even possible? I find I don’t open the Siskin IM app too often and always end up with like +2k messages being downloaded 🫨

  109. singpolyma

    You want to miss messages? Or you mean in public/large channels specifically?

  110. soulcaramel

    Hmm, I hadn’t thought of it as “miss messages” before you said that. I guess in other messaging apps I don’t see it happening but it actually does happen in the background

  111. lissine

    soulcaramel: I think gajim lets you decide how many days of history you want to fetch from group chats / channels

  112. soulcaramel

    @lissine thanks!

  113. soulcaramel

    I’m learning a bit about the history of XML and JSON and wanted ask some of the xmpp contributors opinions on the data formats—being a contributor matters here since they deal with the data—and whether they’d prefer JSON over XML. This is a thought experiment question; I’m not a contributor and have no opinion on which is used

  114. Zash

    soulcaramel, I'd recommend against that.

  115. soulcaramel

    Ok! I’m interested in hearing why since I’m looking into the technical details of xmpp to better understand it

  116. soulcaramel

    FWIW my only experience is in web development so I’ve only ever used json

  117. lovetox

    it does not matter much in my opinion, both are good enough for the job. If your messaging client is a success or failure will certainly not depend on JSON vs XML

  118. moparisthebest

    Agreed

  119. moparisthebest

    But if you go json you will inevitably find yourself reinventing the wheel, ie https://www.moparisthebest.com/images/jsonschema.jpg

  120. soulcaramel

    Omg this made me laugh out loud

  121. soulcaramel

    😂

  122. soulcaramel

    And understood on json/xml not being the limiting factor