XSF Discussion - 2018-01-04

  1. ralphm

    Hi all

  2. MattJ


  3. ralphm bangs gavel

  4. Ge0rG

    What? End of Meeting?

  5. ralphm

    0. Welcome and agenda

  6. ralphm

    Who do we have?

  7. MattJ

    I'm here

  8. MattJ

    Guus and Martin both said they couldn't make it today

  9. ralphm


  10. ralphm

    and no nyco?

  11. ralphm

    Ok, so no quorum. Let's try next week and follow up on list.

  12. ralphm bangs gavel

  13. MattJ


  14. Ge0rG

    ralphm: don't forget to change the topic for our multi-year ongoing Board meeting

  15. ralphm set the topic to

    XSF Discussion | Logs: http://logs.xmpp.org/xsf/ | Agenda https://trello.com/b/Dn6IQOu0/board-meetings

  16. ralphm


  17. Ge0rG


  18. Ge0rG

    thanks very much.

  19. Ge0rG

    BTW, whom should I approach about the administration of jabber.org and xmpp.org the Jabber servers?

  20. jonasw

    stpeter maybe?

  21. jonasw

    xmpp.org is iteam

  22. jonasw

    xmpp.org isn’t a public server in any way though

  23. jonasw


  24. Kev

    Iteam for xmpp.org. Peter for jabber.org. Although you can always approach me and see if I can help.

  25. Ge0rG

    Maybe I should just make it (more) public now.

  26. jonasw

    your manifesto?

  27. Ge0rG

    Kev: I'm working on a Public Servers Anti-Spam manifesto - https://gist.github.com/ge0rg/2e4accf6950821ca45f743fdf587c08e - I'd like to get some feedback from large public servers' admins to create a consensus that can be signed off

  28. mathieui

    if only the third item was possible

  29. Ge0rG

    mathieui: monitoring registrations from TOR?

  30. mathieui


  31. Ge0rG

    mathieui: it is possible, at least on prosody

  32. Kev

    I think it's millions of users, FWIW, although not all active.

  33. Kev

    jabber.org has millions of registered users on its own.

  34. mathieui

    well, if "monitoring" consists of adding one log line to the prosody debug file, then sure, it’s possible

  35. mathieui

    but also useless

  36. Ge0rG

    mathieui: you can have a script grep your log

  37. moparisthebest

    And do what

  38. moparisthebest

    Xmpp over tor is perfectly legitimate

  39. jonasw

    moparisthebest, treat the accounts with more scrunity until it’s clear they’re not abusers?

  40. jonasw

    limit resource usage etc.

  41. mathieui

    moparisthebest, it’s perfectly legitimate but mass account creation is not

  42. jonasw

    protecting public servers against tor-helped abuse is also perfectly legitimate :)

  43. moparisthebest

    jonasw: sounds hard for a script but sounds ok

  44. mathieui

    also from my homemade statistics we’ve got around 1000 registrations for one legitimate user from those ips

  45. Ge0rG

    > protecting public servers against tor-helped abuse is also perfectly legitimate :) We really need to differentiate here. There _are_ legitimate use cases for Tor

  46. jonasw

    Ge0rG, that’s why I’m saying "tor-helped abuse" and not "tor itself"

  47. mathieui

    yeah, it’s not about banning Tor at all (hell, I run a relay myself)

  48. moparisthebest

    So will there be a public list of servers that should be blocked or will that be up to individual servers to determine

  49. jonasw

    I suggested to run a public DNS block list

  50. jonasw

    but Ge0rG was against the name I proposed :)

  51. moparisthebest

    That would be ideal, but then someone has to manage it

  52. jonasw

    I wanted to try that

  53. moparisthebest

    The reason it's ideal is because large servers have enough info to determine bad domains, small servers do not

  54. jonasw


  55. moparisthebest

    And I'm biased, I'm the only one on my server to get spam :)

  56. Ge0rG

    jonasw: I was not opposed to you actually running it, but you might give it a better name, like xmpp-rbl

  57. jonasw

    I know

  58. jonasw

    RBL doesn’t seem to be a reasonable name though

  59. jonasw

    because it won’t be real-time or blackhole, will it?

  60. Kev

    Is there any reason for it to be DNS-based for XMPP?

  61. jonasw

    Kev, exploiting existing cache infrastructures and speed?

  62. Kev

    But you're talking about running your own, aren't you?

  63. jonasw

    what does that have to do with anything?

  64. jonasw

    with existing cache infrastructtures, I mean global and local resolvers

  65. Kev

    "Exploiting existing infrastructure" and "bringing your own new infrastructure" don't seem compatible.

  66. jonasw

    DNS is also easily replicated

  67. Kev

    Anyway, I don't have a particular reason it needs to not be DNS.

  68. Ge0rG

    jabber.org doesn't have offline storage :(

  69. Kev

    It doesn't?

  70. Ge0rG


  71. Kev

    I don't remember that being disabled.

  72. Ge0rG

    At least I get `503 - cancel: Service unavailable` when messaging stpeter

  73. Kev

    I just tested on myself, and it worked.

  74. Ge0rG

    I never was able to message stpeter when he wasn't online.

  75. jonasw


  76. Ge0rG


  77. SamWhited


  78. Ge0rG

    syn ack

  79. SamWhited


  80. SamWhited

    wow, took a,long time to send but apparently I can connect for free on Delta flights' terrible wifi.

  81. Ge0rG

    SamWhited: your `syn?` was delivered twice.

  82. mathieui


  83. mathieui

    I have that from time to time with conversations

  84. SamWhited


  85. Holger

    SM resume fails so Conversations resends to fail on the safe side?

  86. SamWhited

    They claim to only allow Whatsapp, Facebook, and sonething else for free but I can use my server and jmp.chat's SI. server, this is rather nice.

  87. SamWhited

    SIP, even.

  88. Ge0rG

    Holger: shouldn't it wait for the MUC sync to complete before re-sending?

  89. Ge0rG

    SamWhited: maybe they are only blocking HTTP(S) ;)

  90. Holger

    (SM resume fails and the server doesn't include the 'h' attribute with the <failed/> response, that is ...)

  91. jonasw

    Ge0rG, this muc is anonymous, isn’t it?

  92. jonasw

    so there’s no point in syncing

  93. Holger

    Ge0rG: How would that help?

  94. Ge0rG

    jonasw: right, all bets are off.

  95. jonasw

    Holger, if you received the history in a non-anon muc you could be sure whether your message got delivered :)

  96. Ge0rG

    personally, I just ignore impersonation attacks and sync away.

  97. Holger

    jonasw: Hm with some proper ID (origin-id?) I guess so, yes.

  98. marc

    Ge0rG, how did our discussion of user invitation URI end? Do we need the "ibr" query parameter?

  99. Ge0rG

    marc: yes

  100. marc

    Ge0rG, in what case?

  101. marc

    I remeber I agreed that we don't need an action parameter :)

  102. Ge0rG

    marc: the ibr parameter indicates that the preauth token can be used in an IBR request to the server

  103. marc

    Ge0rG, but the authority part of the URI already indicates it

  104. Ge0rG

    marc: wait, we are talking of account invitation?

  105. Ge0rG

    marc: we need a good glossary

  106. marc

    Ge0rG, no, "account creation" uses the "register" action query :)

  107. Ge0rG

    marc: so how does the contact invitation indicate ibr?

  108. marc

    Ge0rG, xmpp://example.com/inviter@example.com?preauth=TOKEN

  109. marc

    xmpp:inviter@example.com?preauth=TOKEN for client-side PARS

  110. moparisthebest

    did you mean https for the first one marc ?

  111. Ge0rG

    marc: so which one of those?

  112. marc

    Okay, wait

  113. marc

    Account creation: xmpp://newuser@example.com/inviter@example.com?register;preauth=TOKEN User invitation: xmpp://example.com/inviter@example.com?preauth=TOKEN Client-side PARS: xmpp:inviter@example.com?preauth=TOKEN

  114. marc

    moparisthebest, no

  115. Ge0rG

    xmpp:inviter@example.com?preauth=TOKEN;ibr is a perfect match for both second and third use case

  116. marc

    Ge0rG, no

  117. Ge0rG

    And the account invitation doesn't need the inviter URL

  118. marc

    The authority part can indicate the domain to create an account

  119. moparisthebest

    not really sure the need for all the different urls but I'll just shut up until I see xep :P

  120. marc

    moparisthebest, no, just ask

  121. moparisthebest

    well what do each of those do?

  122. Ge0rG

    marc: you are making it too complicated

  123. moparisthebest

    and why are there more than one format if all have to be handled by xmpp client?

  124. marc

    moparisthebest, 1: create an account, 2: invite a user and give the choice to register on the server 3: PARS

  125. Ge0rG

    marc: stop adding edge cases. If the inviter and invitee domains differ, this is not our use case any more

  126. moparisthebest

    hmm how is 1 different than 2 ?

  127. moparisthebest

    like how would you get link #1

  128. marc

    moparisthebest, #1 is more or like admin stuff

  129. moparisthebest

    so why isn't it the same?

  130. marc

    Ge0rG, don't get why this makes it more complicated than using an additional "ibr" parameter

  131. moparisthebest

    I still don't see any reason for more than 1 url

  132. moparisthebest

    whatever it may be

  133. moparisthebest

    it looks like all those have exactly the same info in slightly different formats, why?

  134. marc

    moparisthebest, no, they don't

  135. marc

    moparisthebest, because they are different? ;)

  136. moparisthebest

    what is different

  137. moparisthebest

    what info do they have?

  138. moparisthebest

    bet you wish you would have just let me wait for xep now lol

  139. moparisthebest

    you can go back to ignoring me if you want I don't mind :)

  140. marc

    moparisthebest, #1: contains the new account JID (newuser@example.com)

  141. marc

    moparisthebest, #2 contains the domain for IBR (example.com)

  142. moparisthebest

    do they not all contain domain for IBR ?

  143. Ge0rG

    marc: just completely delete #2

  144. moparisthebest

    so looks like 1 & 2 are same except extra useless 'register' and optional account name

  145. marc

    Ge0rG, we already agreed on it ;)

  146. Ge0rG

    marc: on deleting it

  147. Ge0rG

    And implementing the same functionality in #3

  148. marc

    And IIRC you liked the idea of different domains

  149. moparisthebest

    what does 'register' get you?

  150. marc

    moparisthebest, indicates account registration

  151. moparisthebest

    doesn't newuser@ indicate that?

  152. marc

    moparisthebest, no, because newuser is optional :P

  153. moparisthebest

    So what does it do differently

  154. marc

    moparisthebest, as I said, you could have xmpp://example.com/inviter@example.com?register;preauth=TOKEN

  155. marc

    But don't tell Ge0rG :D

  156. Ge0rG

    marc: that won't work if the invitee already has an account!

  157. moparisthebest

    marc: point being you have to check if they have an account or not already so I think it's useless

  158. moparisthebest

    And how do you validate it meh

  159. marc

    Ge0rG, don't get your point

  160. marc

    Ge0rG, you're talking about #1, right?

  161. Ge0rG

    marc: no, #2

  162. marc

    Ge0rG, okay, what's the problem if the invitee already has an account?

  163. marc

    Why doesn't it work? You just show an dialog to add via the PARS token

  164. marc

    And show a short button or whatever that the invitee can also create an account on the server

  165. Ge0rG

    marc: because you need a #3 link for that to work

  166. marc


  167. marc

    Ge0rG, why?

  168. marc

    Ge0rG, if the server doesn't support this XEP the client can generate #3 itself

  169. marc

    As fallback, the user doesn't even notice it

  170. marc

    The same applies if the server doesn't allow IBR for invitation

  171. marc

    It just sends #3

  172. marc

    (This is what you describe as server-side PARS in your XEP)

  173. Ge0rG

    marc: if the server allows ibr and generates the link, I still want it to be in #3 format, because that's most widely supported

  174. Ge0rG

    marc: if the server allows ibr and generates the link, I still want it to be in #3 format, because that's most widely supported

  175. marc

    Ge0rG, if these clients are implemented correctly it is even backward compatible ;)

  176. marc

    Ge0rG, #2 is backward compatible to #3 if you parse the URI properly IMO

  177. Ge0rG

    marc: no, it's something different

  178. marc

    Ge0rG, if you correctly parse the #3 URI you would extract the JID from the "path" component

  179. marc

    The same for #2

  180. marc

    Ge0rG, in #3 the authority part is empty and the JID in the "path" component

  181. Ge0rG

    marc: except that #2 has completely weird semantics with a host as the authority

  182. Ge0rG

    marc: just leave it away, please

  183. marc

    Ge0rG, that's the sematinc of XMPP URIs

  184. marc

    Ge0rG, xmpp:///inviter@example.com?preauth=TOKEN if no domain is provided

  185. Ge0rG

    "this URI points to a jabber server."

  186. Ge0rG

    marc: xmpp:inviter@domain;preauth;ibr is an invitation to a user JID, with the hint that you can register on that domain

  187. marc

    Ge0rG, but you can not provide a good argument why that's a better solution ;)

  188. Ge0rG

    marc: I've provided multiple good arguments multiple times already

  189. marc

    Ge0rG, both are backward compatible

  190. Ge0rG

    marc: I'm on my mobile client right now, and I really don't want to repeat them all

  191. Ge0rG

    marc: there are no clients supporting #2 dnd it has the wrong semantics

  192. marc

    Ge0rG, #1 has the same wrong semantic then?

  193. Ge0rG

    marc: #1 is sharing an account on a server

  194. marc

    Ge0rG, okay, what about xmpp://example.com?register;preauth=TOKEN (#1 without specified username)?

  195. Ge0rG

    marc: I still think we could completely cover most situations with just #3, but #1 adds some value

  196. Ge0rG

    marc: nope! Use #3

  197. marc

    Ge0rG, I'm talking about #1 scenario

  198. marc

    Ge0rG, is this URI correct?

  199. marc

    for #1 scenario...

  200. marc

    No trick question ;) I'll use "ibr" for user invitation

  201. Ge0rG

    marc: if you don't supply a username, just skip the authority completely

  202. marc

    Hm, I don't know but we agree on the following: User invitation: xmpp:inviter@example.com?preauth=TOKEN;ibr User invitation (without IBR, server-side PARS) xmpp:inviter@example.com?preauth=TOKEN

  203. marc

    If the server doesn't support this XEP the client generates #2 itself

  204. marc


  205. Ge0rG

    marc: yes

  206. marc

    Ge0rG, okay, I'll adapt the XEP accordingly

  207. Flow

    marc, is the (proto)xep online somewhere?

  208. Ge0rG

    marc: that is exactly what we agreed about, plus account invitation with xmpp://invitee@domain with a token

  209. marc

    Flow, no, but I can upload it tomorrow or so

  210. Flow