XMPP Service Operators - 2021-06-30


  1. qy

    Caveat emptor

  2. moparisthebest

    tom: sorry to burst your bubble but most of the xeps you use every day aren't draft, only experimental

  3. Харпер

    So is there an ejabber .module to do so?

  4. moparisthebest

    tom: mam, carbons, push notifications to name a few aren't yet draft

  5. rob

    I like living on the edge

  6. rozzin

    moparisthebest: I'll take the XMPP community's "experiments" over most others' "production" any day 😜️

  7. moparisthebest

    I agree

  8. oldelf

    I need someone to talk.

  9. Licaon_Kter

    oldelf: you Ok? Wait...don't go.... ಠ_ಠ

  10. Ellenor Malik

    uh oh

  11. tom

    » [19:31:51] <moparisthebest> tom: mam, carbons, push notifications to name a few aren't yet draft they aren't mandatory

  12. tom

    sorry to burst your bubble

  13. moparisthebest

    only if you want working message delivery :)

  14. moparisthebest

    multidevice

  15. Holger

    Or single mobile device.

  16. Holger

    But who uses mobile these days ...

  17. tom

    then please work on and help other clients obtain implementations of those xeps

  18. moparisthebest

    basically all of them already do?

  19. tom

    oh yeah that's right. Gajim and Conversations == all xmpp clients

  20. jonas’

    and Dino

  21. jonas’

    and poezoi

  22. jonas’

    and poezio

  23. jonas’

    not sure about profanity

  24. moparisthebest

    it'd be easier to name the clients that *do not*, can you name any?

  25. jonas’

    pidgin.

  26. tom

    psi+ only partial support for mam

  27. tom

    only in conferences it works... kinda

  28. tom

    no carbons =(

  29. moparisthebest

    pidgin got a carbons patch 8 years ago, still not merged yet hehe https://developer.pidgin.im/ticket/15508

  30. Holger

    The relevant ones are the mobile clients; i.e. Conversations, Monal, Siskin. They support those.

  31. jonas’

    moparisthebest, so it hasn’t gotten it.

  32. moparisthebest

    then I wouldn't call Psi+ a "maintained client"

  33. tom

    vacuum i think has better mam but probably not carbons

  34. Holger

    Vacumm even has this old-school archiving thing, no?

  35. tom

    moparisthebest: well then your wrong

  36. Holger

    XEP-0136

  37. jonas’

    tom, that line there is a prime example of off-topic

  38. Holger

    (Only client I'm aware of.)

  39. moparisthebest

    I started using xmpp in ~2013 and have never once used a client that didn't support mam and carbons

  40. tom

    you know what's offtopic? calling maintained clients unmaintained just because the development team didn't have the ability to implement $feature you like yet

  41. moparisthebest

    $feature required for basic usage as of at least 2013

  42. jonas’

    ok, sooo… clients are only barely on-topic for this room as it stands, and what is needed for a proprely functioning client is definitely "opinion-based", so I’d prefer if we could leave it at this now :)

  43. Holger

    I totally agree not to make OMEMO mandatory BTW, which started this off and which is kinda on-topic 🙂 Just not with the reasoning.

  44. jonas’

    sure, OMEMO/plaintext transit policies are an on-topic thing to discuss

  45. Ellenor Malik

    OMEMO should just be default

  46. tom

    follow the spec recommendations, they are that way for a reason

  47. Ellenor Malik

    but that's client discussion again

  48. Holger

    On clients who's target audience wants/expects such a default, yes.

  49. tom

    otherwise things start breaking, messages start dropping

  50. tom

    just follow the standards

  51. Sam

    They aren't though. The status of specs change in part based on how many implementations there are. By your logic nothing would ever move past experimental.

  52. jonas’

    standards aren’t perfect though. RFC 6120 is a prime-example, we have bolted on XEP-0198 nowadays becaue of the shortcomings of the interaction of TCP with the reliability expectations of XMPP

  53. tom

    I don't want to be a beta tester for some things

  54. Sam

    This seems to be a misunderstanding of how the XSF treats "Experimental" and "Draft" (which is fair, because those terms are confusing and don't mean what the XSF thinks they mean either).

  55. Sam

    These aren't things in beta, these are well established protocols that the XSF recommends you implement.

  56. Holger

    > don't mean what the XSF thinks they mean either 😀️

  57. jonas’

    Sam, some of them are.

  58. tom

    OMEMO experimental meaning it's subject to change on a whim, and it's probably seriously broken

  59. tom

    as in

  60. jonas’

    not everything in Experimental is a well-established protocol, I hope we can agree on that much

  61. tom

    omemo with it's drop message invisibly into the ether if there's a decrypt failure

  62. Sam

    jonas’: sure, I'm mostly pointing out that tom's logic is flawed by making this comparison with MAM/Carbon/whatever else it was

  63. tom

    having to manually approve every single key

  64. tom

    lack of widespread proper full implementation due to complexity

  65. jonas’

    Sam, fair

  66. tom

    and being constantly in flux

  67. Sam

    I totally agree that OMEMO has UX issues FWIW, but "don't implement it because it's expereimental and that means beta" is just wrong.

  68. tom

    maybe for you, but I'm not going to waste my time implementing something that's going to be obselete in a matter of months

  69. Sam

    And "don't implement Carbons/MAM because they're Experimental" is *very* wrong.

  70. tom

    and I don't want to use 'Experimental tech' for my everyday coms

  71. jonas’

    tom, you do you, that’s fine

  72. Sam

    Carbons and MAM aren't experimental. They're extremely well vetted and widely implemented technology.

  73. Sam

    OMEMO is more debatable.

  74. tom

    if someone wants to help psi+ and vacuum-im implement mam and carbons please do

  75. jonas’

    reminds me, in which state is MAM? didn’t we want to Draft this? what was the blocker…

  76. tom

    but don't spread FUD about clients

  77. tom

    calling them unmaintained

  78. jonas’

    look at that, the last call ended 3 months ago

  79. tom

    they are maintained

  80. tom

    they have git commit history within days ago

  81. tom

    technology doesn't progress in a straight line

  82. tom

    it branches out

  83. Sam

    tom: are you a maintainer? You might want to check the website, it links to the wrong git repo. I had assumed they were unmaintained too for that reason.

  84. jonas’

    Ge0rG vetoed it

  85. tom

    no but i submit patches sometimes

  86. tom

    the website isn't where development is happening github is

  87. tom

    and the github tracker

  88. tom

    i'll link you the repo later, but i have to go to a meeting

  89. Sam

    Yes, and the website is how I went to find the GitHub and it links to the wrong place which makes it look unmaintained (because the repos it links to are unmaintained)

  90. Sam

    I found the right one now.

  91. rozzin

    OMG what did I start... 😳

  92. Ellenor Malik

    :)

  93. rozzin

    > Yes, and the website is how I went to find the GitHub and it links to the wrong place which makes it look unmaintained (because the repos it links to are unmaintained) I really thought that OpenSSL/Debian RNG bug pretty aptly demonstrated how bad an idea "developers hiding out in a secret clubhouse where nobody else can find them" is...

  94. rozzin

    I am going to try to bounce off of this OMEMO discussion to get back on topic, now....

  95. rozzin

    There's a nice index of clients and their support for OMEMO at https://omemo.top/

  96. Licaon_Kter

    rozzin: that's still...offtopic?

  97. Licaon_Kter

    rozzin: that's still...offtopic!

  98. Ellenor Malik

    Jeez :/

  99. rozzin

    ... it would be nice if there were similar indices for other XEPs

  100. Ellenor Malik

    Yeah, like, are we pubsub for nonadmins yet?

  101. Licaon_Kter

    The DOAP thing should help

  102. rozzin

    [boing...] so that it were easy for me to figure out what clients to recommend to my users.

  103. Licaon_Kter

    https://xmpp.org/extensions/xep-0453.html

  104. Licaon_Kter

    https://github.com/iNPUTmice/Conversations/blob/master/conversations.doap https://github.com/dino/dino/blob/master/dino.doap https://github.com/monal-im/Monal/blob/develop/monal.doap

  105. rozzin

    ... because *I'm* the one they complain to when things `don't work right'...

  106. Licaon_Kter

    tom: you can contribute a DOAP to your favourite projects so at least people can know...what's missing :)

  107. Харпер

    What is doap?

  108. Licaon_Kter

    Read xep Харпер

  109. rozzin

    ... and even if it's easy enough to go look up the website for their specific client and say, e.g. "yeah, stop using Pidgin, it breaks all of your expectations"....

  110. Харпер

    A machine parsable list of supported features?

  111. rozzin

    they then want me to recommend options for _replacements_....

  112. rozzin

    Yeah, DOAP looks... like a pretty dope way of getting the straight dope.

  113. rozzin

    So for the clients that publish a public doap file like that, looks like it should be easy to at least put them into a client/feature matrix.

  114. Licaon_Kter

    Oh no...you said matrix :)

  115. rozzin

    So for the clients that publish a public doap file like that, looks like it should be easy to at least put them into a client/feature grid.

  116. rozzin

    🙄️

  117. rozzin

    Anyone feel like building/hosting that? 😉️

  118. tom

    Licaon_Kter: ty

  119. tom

    is there a central repo for doaps or a parser?

  120. tom

    or a centralized lonk to doaps

  121. tom

    what do you do if some xep implementations are done via plugins in a seperate repository?

  122. Licaon_Kter

    I think I saw something on XSF but maybe I just imagined it?

  123. mathieui

    There is a wip stuff of the xsf website which presents clients/servers/libs according to xep support, yes

  124. mathieui

    Ask Link Mauve

  125. mathieui

    No clue how far it is with iteam though

  126. rozzin

    tom: mark it as "[status]*" with a "*=implemented by plugin" footnote?

  127. tom

    LMAO : https://mastodon.matrix.org/@matrix/106501901675235220 there goes that damn protocol again. No graceful degradation, upgrade or your kicked off. No contacting operators before blocking either

  128. tom

    the big centralized server dictating everything for everybody else

  129. mathieui

    Though they have the concept of deactivating a user, something I would like to have in prosody

  130. mathieui

    Having to backup spam user files before purging them for later analysis is a bit painful

  131. Holger

    Scramble the password? (But then reactivation is meh if there's no password reset magic.)

  132. Licaon_Kter

    Imagine if there was "prior-art" of federation and spam...

  133. rob

    😶

  134. moparisthebest

    You gotta admit, it's certainly easier to do it that way

  135. moparisthebest

    Hey you 4 other admins, upgrade ok? Thanks.

  136. rob

    Upgrade what now?

  137. moparisthebest

    rob: the entire XMPP network (I was making fun of the linked matrix post)

  138. rob

    Oh, ya matrix is not good