jdev - 2024-06-24


  1. jjj333_p (any pronouns)

    > jjj333_p (any pronouns): It is better to look recent https://github.com/xmppo/go-xmpp is this better to use than /FluuxIO/ ?

  2. jjj333_p (any pronouns)

    sorry if thats sounding stupid

  3. lbocquet

    And there is this MUC Room to talk about go-xmpp: xmpp:go-sendxmpp@chat.mdosch.de?join

    👍 1
  4. jjj333_p (any pronouns)

    and my wifi died, great

  5. singpolyma

    >> Definitely not abandoned, what makes it seem that way? > only a minor commit within the last 2 years Well, xmpp hasn't exactly changed in the last 2 years, so that seems expected to me.

  6. jjj333_p (any pronouns)

    > Well, xmpp hasn't exactly changed in the last 2 years, so that seems expected to me. mmm got it

  7. Hanketsu

    hol up

  8. Hanketsu

    jjj333_p?

  9. jjj333_p (any pronouns)

    > jjj333_p? yes?

  10. taba

    github is LITERALLY owned by microsoft

  11. taba

    > ive never understood why people prefer the central codeberg instance to github. theyre both centralized jjj333_p (any pronouns), because codeberg maintainers aren't necessarily evil? literally just open the website https://codeberg.org

  12. jjj333_p (any pronouns)

    > github is LITERALLY owned by microsoft i know, but i percieve it as kinda disjointed since github allows many things explicitly related to msft software piracy and things

  13. jjj333_p (any pronouns)

    also imo github has the only tolerable ui of all the git versions

  14. taba

    > i know, but i percieve it as kinda disjointed since github allows many things explicitly related to msft software piracy and things for now...

  15. taba

    > also imo github has the only tolerable ui of all the git versions i disagree but it's irrelevan to the chatroom

  16. jjj333_p (any pronouns)

    > jjj333_p (any pronouns), because codeberg maintainers aren't necessarily evil? literally just open the website https://codeberg.org i mean its all public data out there. anyone can still scrape it and do whatever they want

  17. taba

    not how it works. every project suddenly switching the url would break much of foss

  18. taba

    github has some leverage

  19. moparisthebest

    >> jjj333_p (any pronouns), because codeberg maintainers aren't necessarily evil? literally just open the website https://codeberg.org > i mean its all public data out there. anyone can still scrape it and do whatever they want No they can't. They can do what the license allows or nothing at all.

  20. jjj333_p (any pronouns)

    > not how it works. every project suddenly switching the url would break much of foss no i just mean like what msft can do with my data. if they wanna train copilot or whatever they can get that from anywhere

  21. jjj333_p (any pronouns)

    > No they can't. They can do what the license allows or nothing at all. legally*

  22. jjj333_p (any pronouns)

    youre naive if you think that extends to what they can successfully avoid getting caught doing

  23. taba

    > no i just mean like what msft can do with my data. if they wanna train copilot or whatever they can get that from anywhere any amount of effort spent on getting something working with or on github gives power to it

  24. taba

    not doing so is good for everyone

  25. taba

    > youre naive if you think that extends to what they can successfully avoid getting caught doing jjj333_p (any pronouns), didn't microsoft literally acquire github just to then train copepilot?

  26. taba

    that's what everyone using github got for their effort

  27. jjj333_p (any pronouns)

    > any amount of effort spent on getting something working with or on github gives power to it eh until i find a git instance with decent ui and seo its the most tolerable for me. im always open to other options

  28. jjj333_p (any pronouns)

    and gittea/forejo i aint considering until they have federation because i do not want to make 5 billion accounts

  29. taba

    > seo you also give power to google as well

  30. jjj333_p (any pronouns)

    > > seo > you also give power to google as well well i would like people to actually be able to find my projects

  31. jjj333_p (any pronouns)

    if youre going to fault me for that i dont have the time to listen to you

  32. taba

    > decent ui fair, but last i checked project maintainers LITERALLY ask you to change your behavior to account for how commit history looks on github

  33. taba

    play stupid games win stupid prizes

  34. jjj333_p (any pronouns)

    > > decent ui > fair, but last i checked project maintainers LITERALLY ask you to change your behavior to account for how commit history looks on github i have not come across that

  35. jjj333_p (any pronouns)

    and my #1 example is the language graph. all the other ones rely on js so that you hover over a small bar and it displays a label

  36. taba

    there are people who avoid merges because it looks bad on github

  37. jjj333_p (any pronouns)

    > there are people who avoid merges because it looks bad on github yeah ive never come across that

  38. taba

    it leads to nonsensical behavior

  39. jjj333_p (any pronouns)

    i kinda feel like youre cherrypicking examples, just because of how rarely ive seen that myself

  40. jjj333_p (any pronouns)

    anyways i have better things to do than argue about what git instance i use, imma go touch grass.

  41. taba

    i've been told to stop merging and use rebase solely to make github pretty

  42. taba

    one of the points was that merges look bad on github

  43. taba

    in this way and i think it's stupid in general

  44. taba

    recently

  45. taba

    qy, mike, singpolyma and i think rozzin were talking about git merges, rebases and squashes

  46. taba

    it's not cherrypicking if it describes the reality of how stupid github's ui is

  47. taba

    xmpp fucked up message order again

  48. taba

    thanks xmpp

  49. taba

    > anyways i have better things to do than argue about what git instance i use, imma go touch grass. same

  50. taba

    https://codeberg.org/forgejo/forgejo/graph

  51. taba

    how is this not simply better

  52. taba

    how long has codeberg and whatever backend it uses had

  53. taba

    how long has codeberg and whatever backend it uses had this

  54. taba

    > https://codeberg.org/forgejo/forgejo/graph first time opening this. i just assumed it would have it

  55. taba

    ok i'll shut up

  56. jjj333_p (any pronouns)

    > https://codeberg.org/forgejo/forgejo/graph ooo okay thats hot

  57. jjj333_p (any pronouns)

    tbf i dont do a lot of colaboration so its fine

  58. jjj333_p (any pronouns)

    i also usually squash and merge for merges so i dont have too much of a prob lem

  59. jjj333_p (any pronouns)

    https://downloadable.pain.agency/file_share/WB672ZThzAFk4tS58pv7-AO2/2cdc584f-87c9-44ee-9c85-b8a87935518e.png

  60. jjj333_p (any pronouns)

    this is one of the things i dont see how other git instances get right

  61. jjj333_p (any pronouns)

    https://downloadable.pain.agency/file_share/JriBWwQZ06zByptO3BUq6qNF/0a3628fd-0196-4687-a792-e3a2d1576f45.png

  62. jjj333_p (any pronouns)

    the other ones you have to hover to see those labels for some reason

  63. taba

    personally don't care as it's always obvious from the readme or file extensions

  64. lovetox

    on a delay stanza for offline messages, some servers add from=domain some from=accountjid

  65. lovetox

    is there a right or wrong here?

  66. moparisthebest

    Hmm does it deleted on who delayed them

  67. moparisthebest

    Hmm does it depend on who delayed them

  68. lovetox

    its a offline message

  69. lovetox

    its not "delayed" because of some kind of service outage

  70. moparisthebest

    Ah right the before mam thing

  71. Zash

    It's delayed because no offline client could accept it, thus delayed by the receiving users server/account entity.

  72. singpolyma

    Domain feels most right to me, but bare jid also seems probably fine?

  73. moparisthebest

    > It's delayed because no offline client could accept it, thus delayed by the receiving users server/account entity. Classic server dev, blaming the user 🤣 It is convincing though

  74. lovetox

    i will accept both as it seems ..

  75. lovetox

    other question, is https://xmpp.org/extensions/xep-0013.html widley supported

  76. lovetox

    which means ejabberd and prosody

  77. lovetox

    which means ejabberd and prosody?

  78. lovetox

    i would consider using <purge/> if mam is available

  79. singpolyma

    If you rely on mam users will miss messages unless their archiving is set to Always which is not the default on many servers. Or if they are away longer than the mam retention limit

  80. moparisthebest

    I cannot imagine it is... Looks like a relic from single client days

  81. lovetox

    > If you rely on mam users will miss messages unless their archiving is set to Always which is not the default on many servers. Or if they are away longer than the mam retention limit why would a server store offline messages longer than mam retention?

  82. Zash

    > i would consider using <purge/> if mam is available I believe Conversations + ejabberd does this.

  83. Zash

    > which means ejabberd and prosody? Prosody does not, I think we have something else to solve that? MattJ ?

  84. singpolyma

    >> i would consider using <purge/> if mam is available > I believe Conversations + ejabberd does this. Seems unsafe

  85. Zash

    https://hg.prosody.im/trunk/rev/d66738eeb875

  86. lovetox

    no mam is broken in a multi device setup, so i doubt there is real use case today to disable mam

  87. lovetox

    Zash that would mean i need to request mam before sending precences

  88. Zash

    yup

  89. Zash

    https://chat.modernxmpp.org/log/modernxmpp/2021-08-31 has some further discussion that lead to that

  90. lovetox

    hmmm

  91. lovetox

    i wonder if this is smart

  92. lovetox

    can i join a MUC without sending presence to the server ? probably not

  93. Zash

    sure you can

  94. Zash

    joining a MUC without sending initial presence is fine

  95. Zash

    probably a sensible thing for some bots to do 🤷️

  96. Zash

    lovetox, as mentioned there, the longer term idea is to fix this with BIND 2.0 somehow

  97. lovetox

    yeah i think i will just fix the delay timestamp parsing

  98. lovetox

    to add special ways to prevent this on different servers, is not worth the effort

  99. lovetox

    in most cases people have multiple devices, and this situation that they go online with only one will not happen often

  100. Zash

    you can fwiw turn off offline messages in prosody and mam will cover most messages

  101. Zash

    but then if you ever stay offline for over a $retention-period, the oldest messages are lost

  102. Zash

    one day we'll do something about that too

  103. Zash

    one day!

  104. singpolyma

    > no mam is broken in a multi device setup, so i doubt there is real use case today to disable mam Sure but many many servers have it set to either Never or Contacts by default. And also have expiry set to 7 days or something like this, unconditionally

  105. lovetox

    yeah thats for me user hostile

  106. lovetox

    and i plan to implement a dialog that checks that, and offers the user a button where Gajim reconfigures that

  107. MattJ

    "Never" and "Contacts only" are stupid behaviours, and I regret that this was ever in XEP-0313

  108. MattJ

    What I would like to see happen next is the deprecation of that configuration protocol, and a replacement that allows you to 1) configure retention on a per-account basis, 2) request a manual purge of the archive

  109. moparisthebest

    > can i join a MUC without sending presence to the server ? probably not lovetox: I would go further and say this is the right way to do it, I'd like to see clients have 2 seperate streams by default, one without presence/carbons/etc for MUCs and one with for 1:1, so busy MUCs never head-of-line block 1:1 stuff :)

  110. moparisthebest

    It's even free with quic

  111. lovetox

    > lovetox: I would go further and say this is the right way to do it, I'd like to see clients have 2 seperate streams by default, one without presence/carbons/etc for MUCs and one with for 1:1, so busy MUCs never head-of-line block 1:1 stuff :) hmm but how would you make the server send messages to the 1:1 stream?

  112. lovetox

    hm would the server not route 1:1 message to the muc stream, because the muc stream never sent presence?

  113. lovetox

    i mean it sounds like a crazy idea, where is the drawback?

  114. lovetox

    the drawback is much more complexity on the client side, i have only one database but two streams who want to write to it etc, not thanks :D

  115. lovetox

    i take that little slower muc join

  116. moparisthebest

    > hm would the server not route 1:1 message to the muc stream, because the muc stream never sent presence? Yes

  117. moparisthebest

    > the drawback is much more complexity on the client side, i have only one database but two streams who want to write to it etc, not thanks :D Why is that more complex? They don't conflict, no races or anything.

  118. moparisthebest

    > i take that little slower muc join That's not the problem. The problem is the MUC traffic delays your emergency phone call so you miss it 🥲

  119. lovetox

    i have no experience with that, but i guess python will block on each write, so in essence it will be the same as when i receive all stanzas not in parallel

  120. lovetox

    if you say know, i have to do both streams in different threads, then i tell you that my GUI supports only drawing in one thread, so this will block

  121. moparisthebest

    Surely not nearly as much

  122. lovetox

    maybe, anyway interesting approach when writing a new client :)

  123. lovetox

    i wait for the brave soul, to report their findings

  124. moparisthebest

    You support multiple accounts already, how is this different?

  125. lovetox

    if you treat it like a further account, there is indeed no difference

  126. lovetox

    but im not sure if this would be really a big difference

  127. lovetox

    the network library receives data from different connections in different threads, but once received i get a callback from all in the same thread

  128. lovetox

    the processing of the stanzas, writing to the database, pushing it to the GUI code, is in my experience the bottleneck

  129. lovetox

    i dont need more data from connections

  130. lovetox

    at least thats my experience with Python and GTK, could be different for other setups

  131. singpolyma

    When I do urn:xmpp:bookmarks:1+notify am I not saying that I'd like to see all my contacts bookmarks as well? and the only reason I don't get them is that they probably don't make them public?

  132. Zash

    Yup https://xmpp.org/extensions/xep-0223.html

  133. singpolyma

    seems like we'd ideally just say that we only want our own, regardless of what our contacts publish...

  134. lovetox

    you think this makes a notable difference on the server side?

  135. lovetox

    you think this makes a noticable difference on the server side?

  136. lovetox

    as i understand it the server adds you to a list of interested parties of that node, once you sent that in disco info

  137. lovetox

    how does the +notify evern work, does every remote server of my contacts query my disco info?

  138. qy

    >> i take that little slower muc join > That's not the problem. The problem is the MUC traffic delays your emergency phone call so you miss it 🥲 i'm in 100ish mucs. starting an xmpp client, it takes ...a while, before everything syncs up

  139. moparisthebest

    same...

  140. lovetox

    thats mostly though because of presence spam or

  141. moparisthebest

    Probably

  142. wgreenhouse

    the answer is to not disconnect