XSF Discussion - 2019-03-22


  1. Ge0rG

    Phew. Council duties completed. Only delayed by a week and some.

  2. edhelas

    is there known clients that are implementing https://xmpp.org/extensions/xep-0367.html ?

  3. MattJ

    HipChat, and a bot I wrote

  4. MattJ

    *HipChat (RIP)

  5. edhelas

    oh really ?

  6. edhelas

    I'm planning to implement it in Movim

  7. MattJ

    Great! :)

  8. Guus

    I discussed XEP-0367 with Dele Olajide the other day

  9. Guus

    as a suggestion for Pade

  10. MattJ

    Yes, I really would like to see it more widely implemented

  11. MattJ

    Some work was started for Dino, but afaik that's about it so far

  12. pep.

    Reactions?

  13. MattJ

    Message attaching

  14. MattJ

    Which I think it possibly not the best name, to be honest

  15. Zash

    So what's the deal with attaching vs references?

  16. pep.

    Right, I was going to ask

  17. MattJ

    Exactly

  18. Zash

    Was this something discussed at the summit?

  19. pep.

    Not this specific subject iirc, or at least not this year, but we've had this discussion before on xsf@ at least

  20. MattJ

    References is still full of TODOs and has various open issues regarding how to count characters, etc.

  21. Dele Olajide

    >Guus: I discussed XEP-0367 with Dele Olajide the other day Yes Indeed. That was for emoji reactions

  22. Seve

    That XEP needs some work though, I wonder if it should be splitted, one for reactions and one for attachments. Problem is, you cannot decide what should go first if multiple things are attached (like reactions and images and whatnot)

  23. Zash

    XEP-0377: Spam Reporting https://xmpp.org/extensions/xep-0377.html Is there still interest in this or something like it?

  24. Zash

    IIRC someone thought it should be detached from xep-191

  25. lovetox

    yes i think its better

  26. lovetox

    otherwise you remove any chance this gets send without a blocking action

  27. lovetox

    which will then lead to some hacks like send blocking iq without item or stuff like that

  28. lovetox

    but interest must come from server operators i guess

  29. lovetox

    i think this is useful and most applications have a spam button

  30. Zash

    What comes first, XEP or server? Or client?

  31. MattJ

    Why would you want to report spam and *not* block the sending JID?

  32. moparisthebest

    honeypot?

  33. MattJ

    What about it?

  34. jonas’

    depending on the honeypot use-case, one might want not to actually populate a blocklist to further observe the spambots behaviour before termination

  35. lovetox

    MattJ, i dont know, but why do you want to rob us of the possibility to do so ?

  36. jonas’

    save all the roundtrips.

  37. jonas’

    also atomic operations are nice

  38. lovetox

    spamreporting is not a operation that happens so often that we would have to consider efficiency

  39. lovetox

    i would argue

  40. jonas’

    (I agree with you)

  41. lovetox

    either way, this should come in that or another form

  42. MattJ

    I don't really understand why people want to reject the simple solution here

  43. lovetox

    Whats not simple about the other solution?

  44. lovetox

    and nobody rejects it

  45. MattJ

    Sending two iqs?

  46. jonas’

    we all love the simple (2 IQ) solution

  47. lovetox

    no sending one iq to report spam

  48. MattJ

    and then not blocking the JID

  49. MattJ

    ?

  50. Zash

    Code is probably going to be pretty simple either way

  51. MattJ

    The server is likely going to block it anyway

  52. MattJ

    So whatever, go ahead, I won't object :)

  53. jonas’

    hm, having it in one operation has the advantage that there’s something to lose for the user for reporting false spam

  54. MattJ

    jonas’, yes, that came up before. Didn't mention it now because it's easy to argue against - just send a second iq to unblock

  55. jonas’

    sure

  56. MattJ

    But I consider it a nicer UI to report+block at the same time

  57. MattJ

    Other systems don't have two separate buttons

  58. lovetox

    what if some server wants to tell another server that he blocked a server or jid?

  59. MattJ

    lovetox, that is not what this protocol is for

  60. Zash

    Does it really matter that much on the wire?

  61. MattJ

    lovetox, and if you want this protocol to do those kinds of things, there are many many previous XEPs that do this

  62. MattJ

    and they got nowhere, because they are too complex and impractical in reality

  63. lovetox

    MattJ but making it not dependend on blocking makes it able to easily reuse for use cases we didnt think about

  64. lovetox

    but ok i see there are pro and cons

  65. MattJ

    There are various components to consider with battling spam

  66. lovetox

    it doesnt matter let this get advanced

  67. MattJ

    One of these components is the ability for users to report spam that has slipped through the net

  68. MattJ

    It is unrelated to the other components, it's a feedback mechanism

  69. lovetox

    i understand that if executed by the user this will be 99.99% with a blocking

  70. Zash

    If you see it as block(jid, [reason]) then the current thing seems fine

  71. lovetox

    my argument was, its not reusable in other circumstances we didnt think of

  72. MattJ

    lovetox, that kind of argument leads to generic complex XEPs, of which we have many

  73. lovetox

    but yeah we can always add another XEP for that

  74. MattJ

    and nobody knows how to use them sensibly

  75. MattJ

    Because they support using them in so many different ways

  76. MattJ

    I'm currently fighting to tie up all those loose ends and document them, I don't want to introduce more

  77. lovetox

    store hints come to mind

  78. lovetox

    was this XEP ever put to last call or vote?

  79. MattJ

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

  80. MattJ

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

  81. MattJ

    Hmm, what's the other one

  82. lovetox

    hm ok abuse report seems exactly what i asked about

  83. lovetox

    ip is a bit lol

  84. lovetox

    but ok

  85. MattJ

    lovetox, but someone might need it!

  86. MattJ

    lovetox, for example service operators who want to report bots registering on their server

  87. lovetox

    we really have a problem with people adding XEPs but than dont follow through

  88. Zash

    > Kev: yes, XEP-268 (instant reporting), XEP-236 (Abuse), XEP-287 (SPIM markers and reports), XEP-377 (SPAM reporting).

  89. Zash

    https://wiki.xmpp.org/web/Minutes_of_the_2018_Summit:_Day_two#3._SPAM

  90. MattJ

    lovetox, because "following through" typically requires multiple interoperable implementations

  91. MattJ

    which a single XEP author can't do, and even if everyone in the individual projects agrees it's a good thing to do, there are other priorities...

  92. lovetox

    for draft status you dont need implementations or?

  93. MattJ

    No, but I'm assuming by "follow through" you include implementing

  94. lovetox

    hm no i meant the author adjusts the xep after feedback

  95. MattJ

    Oh right, sure

  96. lovetox

    it seems people maybe think experimental xeps are not changed, so they add new ones

  97. lovetox

    because i dont see why the first abuse report XEP 161 could not add the example to use it with blocking

  98. Zash creates https://wiki.xmpp.org/web/Spam

  99. Zash

    What XEPs are there, what's the good and bad of each? Write down there.

  100. Zash

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

  101. MattJ

    Ah, that's the one I was looking for

  102. MattJ

    It perfectly fits "easy to reuse for use cases we didn't think about" :)

  103. MattJ

    It doesn't fit "easy to use"

  104. Zash

    I think 377 is more in the spirit of simple clients, complex servers

  105. Zash

    IODEF might be fine to generate from the server and send wherever

  106. MattJ

    Yes, agreed

  107. Ge0rG

    I know that I sound like a broken record, but in the current situation, if a user needs to report spam, it essentially means the admin is a lazy bastards who doesn't do due diligence

  108. Zash

    Yes

  109. MattJ

    Ge0rG, so you filter 100% of spam?

  110. MattJ

    and I know you don't, so follow-up question: wouldn't you like feedback to know about stuff that slipped through your net?

  111. Zash

    This mostly being taken care of by server-side black box magic does reduce the apparent need of these reporting mechanisms

  112. Ge0rG

    the deployment of a reporting mechanism prior to a black box magic filter won't do anybody any good.

  113. MattJ

    The black box magic filter needs data

  114. Zash

    Black box 22

  115. Ge0rG

    I'm in the position to make use of such a reporting, because I'm filtering out 99% of spam, so I'll only receive maybe 0.1% of reports. Other server admins don't have a black box, so they are going to receive 10% of their server's spam. Based on the typical 10% engagement rate.

  116. MattJ

    Sure

  117. Ge0rG

    We need to teach everybody to walk before giving them wings.

  118. MattJ

    But I'd argue that it is better to have the mechanism in the server and clients, even if it isn't connected to anything more than "block this JID"

  119. Ge0rG

    MattJ: no. It's actually worse.

  120. MattJ

    Waiting until we perfect magic boxes until we deploy this is the wrong approach

  121. Ge0rG

    MattJ: blocking an individual JID won't have any impact on the amount of spam received by a user. But the ineffectivity of the spam report button will teach them not to use it.

  122. MattJ

    I'm not sure I agree with that

  123. MattJ

    (that they won't use it)

  124. Ge0rG

    MattJ: if you find out that something doesn't work, will you keep using it?

  125. MattJ

    If it's as easy to click "close tab" as it is to click "report and close tab"

  126. MattJ

    They won't find out, that's the beauty

  127. Ge0rG

    It's never as easy.

  128. MattJ

    I receive spam in my inbox, I still report it

  129. Ge0rG

    They report and block, half an hour later they receive the same spam from a different JID.

  130. Zash

    The Algoritm thanks you for the input.

  131. MattJ

    Ge0rG, I'm not denying that will happen

  132. Ge0rG

    MattJ: you also assume that your report isn't merely silently logged into prosody.log without any further action

  133. MattJ

    Do I?

  134. MattJ

    I think you're over-thinking things on behalf of users

  135. MattJ

    If they continue to receive spam they'll likely just stop using the service, client, protocol

  136. MattJ

    regardless of whether there was a report button or not

  137. MattJ

    So the absence of a report button is really not a fix for anything

  138. MattJ

    (I have actually lost contacts who stopped using XMPP entirely when they received daily spam)

  139. Ge0rG

    Ah, it's too late already.

  140. Zash

    WE'RE DOOMED

  141. Ge0rG

    You can do whatever you want, and you can deploy whatever you want, wherever you want. Feel free to focus your efforts on re-solving the 99% of spam problem.

  142. pep.

    I know many people who just continue using IRC/Freenode even with the spamwaves when server operators are almost useless.. I don't think a button would help much during these tbh

  143. mathieui

    freenode is kind of a specific population

  144. mathieui

    (and even then, spam is much easier to deal with in a single IRC network)