XSF Discussion - 2017-12-13


  1. daniel has joined

  2. arc has left

  3. arc has joined

  4. arc has left

  5. Ge0rG has left

  6. arc has joined

  7. jjrh has left

  8. jjrh has left

  9. Holger has left

  10. uc has joined

  11. lskdjf has left

  12. lskdjf has joined

  13. daniel has left

  14. lumi has joined

  15. goffi has left

  16. daniel has joined

  17. sonny has joined

  18. Holger has left

  19. daniel has left

  20. daniel has joined

  21. sonny has joined

  22. sonny has left

  23. blabla has joined

  24. jjrh has left

  25. sonny has joined

  26. lskdjf has left

  27. lumi has joined

  28. daniel has left

  29. daniel has joined

  30. lskdjf has joined

  31. Alex has joined

  32. tux has joined

  33. daniel has left

  34. daniel has joined

  35. daniel has left

  36. daniel has joined

  37. valo has joined

  38. valo has joined

  39. la|r|ma has left

  40. Tobias has left

  41. daniel has left

  42. la|r|ma has left

  43. daniel has joined

  44. Tobias has joined

  45. sonny has joined

  46. matlag has left

  47. lskdjf has joined

  48. arc has left

  49. arc has joined

  50. matlag has joined

  51. Link Mauve has left

  52. Link Mauve has joined

  53. Alex has left

  54. matlag has left

  55. daniel has left

  56. daniel has joined

  57. Guus has left

  58. sonny has joined

  59. arc has left

  60. arc has joined

  61. daniel has left

  62. arc has left

  63. daniel has joined

  64. arc has joined

  65. daniel has left

  66. daniel has joined

  67. daniel has left

  68. arc has left

  69. arc has joined

  70. @Alacer has left

  71. @Alacer has joined

  72. arc has left

  73. arc has joined

  74. uc has joined

  75. arc has left

  76. arc has joined

  77. daniel has joined

  78. arc has left

  79. arc has joined

  80. efrit has joined

  81. daniel has left

  82. sonny has joined

  83. daniel has joined

  84. daniel has left

  85. jere has joined

  86. efrit has left

  87. efrit has joined

  88. SamWhited has left

  89. daniel has joined

  90. Syndace has left

  91. Syndace has joined

  92. efrit has left

  93. jere has joined

  94. mimi89999 has joined

  95. Guus has left

  96. Guus has joined

  97. arc has left

  98. arc has joined

  99. arc has left

  100. sonny has joined

  101. arc has joined

  102. jmpman has joined

  103. jmpman has joined

  104. jmpman has left

  105. jmpman has joined

  106. jere has joined

  107. arc has left

  108. arc has joined

  109. uc has left

  110. daniel has left

  111. arc has left

  112. daniel has joined

  113. arc has joined

  114. daniel has left

  115. daniel has joined

  116. daniel has left

  117. daniel has joined

  118. daniel has left

  119. daniel has joined

  120. zinid has joined

  121. intosi has joined

  122. sonny has joined

  123. Zash has left

  124. Zash has left

  125. Zash has joined

  126. zinid has left

  127. jere has joined

  128. Bunneh has left

  129. Bunneh has joined

  130. Bunneh has left

  131. Bunneh has joined

  132. zinid has joined

  133. daniel has left

  134. Bunneh has left

  135. Bunneh has joined

  136. Bunneh has left

  137. Bunneh has joined

  138. daniel has joined

  139. Bunneh has left

  140. Bunneh has joined

  141. Bunneh has left

  142. Bunneh has joined

  143. uc has left

  144. Bunneh has left

  145. Bunneh has joined

  146. Bunneh has left

  147. Bunneh has joined

  148. Bunneh has left

  149. Bunneh has joined

  150. Bunneh has left

  151. Bunneh has joined

  152. Bunneh has left

  153. Bunneh has joined

  154. la|r|ma has joined

  155. Bunneh has left

  156. Bunneh has joined

  157. Bunneh has left

  158. Bunneh has joined

  159. Bunneh has left

  160. Bunneh has joined

  161. Bunneh has left

  162. Bunneh has joined

  163. daniel has left

  164. daniel has joined

  165. Bunneh has left

  166. Bunneh has joined

  167. arc has left

  168. arc has joined

  169. arc has left

  170. Bunneh has left

  171. Bunneh has joined

  172. arc has joined

  173. mimi89999 has joined

  174. zinid has left

  175. ralphm has left

  176. sonny has joined

  177. Tobias has joined

  178. zinid has joined

  179. daniel has left

  180. moparisthebest has joined

  181. zinid has left

  182. uc has left

  183. zinid has joined

  184. ralphm has left

  185. ralphm has joined

  186. ralphm has joined

  187. zinid has left

  188. zinid has joined

  189. la|r|ma has joined

  190. la|r|ma has joined

  191. intosi has left

  192. sonny has joined

  193. ralphm has left

  194. marc has joined

  195. tim@boese-ban.de has joined

  196. daniel has left

  197. ralphm has joined

  198. zinid has left

  199. zinid has left

  200. ralphm has left

  201. zinid has left

  202. ralphm has joined

  203. Tobias has joined

  204. jonasw

    edhelas, https://github.com/horazont/aioxmpp/issues/90

  205. jonasw

    some notes on that topic^

  206. jonasw has left

  207. @Alacer has left

  208. @Alacer has joined

  209. @Alacer has left

  210. sonny has joined

  211. @Alacer has joined

  212. ralphm has left

  213. zinid has left

  214. Syndace has left

  215. Syndace has joined

  216. goffi has joined

  217. intosi has joined

  218. Kev has joined

  219. arc has left

  220. arc has joined

  221. ralphm has joined

  222. Kev has left

  223. arc has left

  224. jubalh has joined

  225. arc has joined

  226. arc has left

  227. arc has joined

  228. jonasw

    edhelas, https://github.com/horazont/aioxmpp/issues/90

  229. arc has left

  230. Kev has joined

  231. edhelas

    thx

  232. uc has left

  233. jmpman has left

  234. arc has joined

  235. jmpman has joined

  236. Kev has left

  237. jmpman has joined

  238. jmpman has joined

  239. Kev has left

  240. Kev has left

  241. Kev has joined

  242. Steve Kille has left

  243. lskdjf has joined

  244. ralphm has joined

  245. daniel has left

  246. Steve Kille has joined

  247. ralphm has left

  248. Steve Kille has left

  249. intosi has left

  250. intosi has joined

  251. Kev has left

  252. arc has left

  253. arc has joined

  254. arc has left

  255. uc has left

  256. Kev has left

  257. Kev has joined

  258. marc has left

  259. arc has joined

  260. sonny has left

  261. jubalh has joined

  262. jabberatdemo has joined

  263. sonny has left

  264. jcbrand has joined

  265. ralphm has joined

  266. jabberatdemo has left

  267. lumi has joined

  268. mrkiko has left

  269. mrkiko has joined

  270. arc has left

  271. arc has joined

  272. intosi has left

  273. intosi has joined

  274. arc has left

  275. daniel has left

  276. ralphm has joined

  277. Tobias has joined

  278. arc has joined

  279. ralphm has joined

  280. Tobias has joined

  281. blabla has joined

  282. @Alacer has left

  283. blabla has joined

  284. @Alacer has joined

  285. Steve Kille has left

  286. edhelas

    https://blog.apnic.net/2017/12/12/internet-protocols-changing/

  287. edhelas

    XMPP over UDP for when ?

  288. debacle has joined

  289. sonny has joined

  290. marc

    Ge0rG, just thought about user invitation again, we have to following scenarios, correct? * User invitation: - Client-side PARS (fallback for lazy server operators) - Server-side PARS: For private servers - Server-side PARS or account creation: For private or public servers * Account creation for admins and privileged users

  291. marc

    Ge0rG, the new XEP would cover everything except client-side PARS

  292. Ge0rG

    marc: Server-side PARS: this can work for public and private servers, depending on a server-side config.

  293. marc

    Ge0rG, yes, of course

  294. Ge0rG

    marc: other than that, yes

  295. marc

    Ge0rG, good :)

  296. ralphm has joined

  297. Ge0rG has left

  298. arc has left

  299. arc has joined

  300. Ge0rG

    Interesting in the context of xmpp.net: https://bitrot.sh/post/12-12-2017-osint-ssl-on-xmpp-shodan/

  301. Steve Kille has left

  302. Tobias has joined

  303. arc has left

  304. arc has joined

  305. tim@boese-ban.de has left

  306. lumi has joined

  307. nyco has joined

  308. Syndace has left

  309. Syndace has joined

  310. Kev has left

  311. daniel has left

  312. daniel has joined

  313. ralphm has joined

  314. marc

    Ge0rG, have you thought about token expiration again?

  315. jonasw

    what’s the question about token expiration?

  316. marc

    jonasw, do they expire on generation or when they're used (account creation)?

  317. marc

    jonasw, if they expire on generation: does the server generate PARS-only tokens instead?

  318. Ge0rG

    marc: "expire" implies a time limit

  319. marc

    does the server generate no tokens at all?

  320. jonasw

    huh, how would expiration on generation work, what would that mean? they’re invalid immediately?

  321. marc

    jonasw, no, the server denies token generation of course...

  322. nyco has left

  323. Steve Kille has left

  324. marc

    Ge0rG, yes, a combination of amount and time is probably the best solution

  325. nyco has joined

  326. marc

    however, what shall we do if a user hit this limit?

  327. marc

    +s

  328. marc

    I would prefer an error message like "You generated too many invitations. This feature will be available again on DATE"

  329. intosi has left

  330. intosi has joined

  331. ralphm has joined

  332. Kev has joined

  333. Kev has left

  334. lumi has left

  335. ralphm has joined

  336. valo has left

  337. valo has joined

  338. la|r|ma has joined

  339. ralphm has left

  340. zinid has left

  341. sonny has left

  342. ralphm has joined

  343. Alex has joined

  344. intosi has left

  345. intosi has joined

  346. nyco has left

  347. SamWhited has joined

  348. SamWhited has joined

  349. nyco has joined

  350. la|r|ma has left

  351. la|r|ma has joined

  352. la|r|ma has left

  353. la|r|ma has left

  354. la|r|ma has left

  355. zinid has left

  356. zinid has left

  357. zinid has joined

  358. Ge0rG

    marc: as I said, I consider a limit on the _generation_ of tokens as inappropriate. I would prefer a limit on token _redemption_ instead.

  359. Ge0rG

    marc: technically, it makes sense to limit the number of pending tokens to some arbitrary but large number, like 100, to prevent the user from DoSing the server. In practice, tokens are cheap compared to roster items, avatars and picture uploads.

  360. intosi has left

  361. intosi has joined

  362. stefandxm has left

  363. Holger has left

  364. marc

    Ge0rG, I don't care about how cheap are token generation is but about UX of the invitee

  365. intosi has left

  366. intosi has joined

  367. Ge0rG

    marc: what about the UX of the inviter? 😝

  368. marc

    -are

  369. marc

    Ge0rG, yes, that's also important but less than of the invitee I think

  370. Zash

    They are already deep enough in XMPP that we don't care about their needs!!

  371. marc

    If you receive a token which is valid for 2 hours and use it after an hour and it doesn't work (because too many tokens were used) this looks like a broken system to the invitee

  372. daniel has left

  373. marc

    And you don't want to explain why it didn't work...

  374. marc

    Also you have to store the number of used tokens for every user

  375. nyco has left

  376. nyco has joined

  377. ralphm has joined

  378. Ge0rG

    marc: what's the problem you try to solve with the limit on tokens?

  379. marc

    Ge0rG, too many account creations / too many invites

  380. Ge0rG

    marc: which one of those?

  381. marc

    Ge0rG, that's almost the same ;)

  382. Ge0rG

    marc: no, they are different

  383. marc

    yes, _almost_ the same ;)

  384. Zash

    Too many invites -> oh noes, XMPP is becoming too popular, better stop people!

  385. Ge0rG

    Sufficiently different to make a difference in our discussion.

  386. marc

    Given that a token should be usable if it is not expired ;)

  387. marc

    Zash, not talking about public servers here

  388. Zash

    Oh no, someone popular is inviting all their friends, better stop them!

  389. moparisthebest

    shouldn't 100 friends be enough for anyone Zash

  390. Zash

    marc: Never assumed you were

  391. Ge0rG

    Zash: "a spammer is inviting their botnet to my server"

  392. marc

    Zash, trolling is not helpful

  393. Zash

    I'm not

  394. Ge0rG

    moparisthebest: 10 friends on the free plan

  395. Ge0rG

    Zash: is it possible to disable users in prosody without deleting them?

  396. Zash

    Ge0rG: Probably useful to keep track of the tree of invitations for such events

  397. Ge0rG

    Zash: yes, very useful

  398. marc

    Zash, Okay, then you agree that limiting invitations may be useful, right?

  399. Zash

    marc: Not always.

  400. moparisthebest

    are you talking about a XEP decision or an implementation decision? this sounds like clearly an implementation decision

  401. marc

    Zash, I said "may be useful"

  402. marc

    You don't have to use this option

  403. Ge0rG

    moparisthebest: about how to allow that decision within the XEP

  404. marc

    But there are good reasons for it

  405. Zash

    I haven't followed this that closely tho. Limits on which dimentions exactly?

  406. Zash

    Account creations per invite/token? Tokens per user? Per time?

  407. marc

    Zash, oh come on... but your first reaction is "Too many invites -> oh noes, XMPP is becoming too popular, better stop people!"

  408. Ge0rG

    Zash [16:06]: > Account creations per invite/token? Tokens per user? Per time? This is exactly what I want to know, too

  409. moparisthebest

    and that's exactly why it should be an implementation decision

  410. Ge0rG

    marc: so now what's your user story for limitations?

  411. moparisthebest

    XEP should just say 'server can refuse to supply more tokens with reason'

  412. marc

    Yes, to me it's an implementation decision.

  413. Zash

    marc: What I mean is, putting limits in place that prevents someone from getting all their friends into XMPP might not be in our best interest, assuming we want XMPP to be popular.

  414. marc

    Zash, but some server operators don't want to have 10000 users

  415. marc

    Zash, that's the reason

  416. Zash

    But then, artificial scarcity could possibly drive up the percieved value of an account

  417. marc

    if you run a public server you don't have to care about it and just open it

  418. Ge0rG

    marc: if it's a server implementation decision, it has no place in the XEP 😛

  419. Zash

    Should be up to local policy, probably

  420. nyco has left

  421. marc

    Ge0rG, the limitation (how many tokens per user, per time, etc.) should be implementation defined

  422. marc

    Ge0rG, we have to decide how to inform the user in a proper way

  423. lovetox has joined

  424. Ge0rG

    marc: "with an appropriate error response"

  425. Zash

    If there's a TTL involved, is it not up to the UI to be clear about that?

  426. Zash

    "This is a time limited offer, get them while their hot!"

  427. marc

    Ge0rG, exactly :) But _when_, that's the point. You want to throw an error on account creation. I would throw it on token generation

  428. Ge0rG

    marc: these are different limits.

  429. jcbrand has left

  430. marc

    Ge0rG, so you want to make this also implementation defined?

  431. Zash

    If tokens expire, how would you communicate that except when it is used?

  432. Ge0rG

    marc: no. I want to say you can't avoid errors on account registration

  433. marc

    Zash, for token expiration that's okay

  434. Zash

    If the user who created it is still around, they could possibly be notified

  435. marc

    Zash, but if your tokens are valid for 2 hours and don't get accepted because of some other reaons this is confusing

  436. Ge0rG

    marc: but token lifetime is not communicated to the user!!!

  437. marc

    Ge0rG, why?

  438. Zash

    Which user?

  439. marc

    Ge0rG, should be

  440. Ge0rG

    marc: how?

  441. Ge0rG

    Zash: neither

  442. Zash

    Suppose you could stick a date/timestamp in the token

  443. marc

    Ge0rG, landing page for example?

  444. marc

    You could also apply it as parameter to the URI

  445. Ge0rG

    marc: the landing page is not hosted by the xmpp server, and URL parameters can be manipulated

  446. marc

    Ge0rG, the server can provide a URL

  447. marc

    manipulating the expiration date?

  448. marc

    Are you serious?

  449. marc

    Nobody cares because it is checked by the server anyway

  450. marc

    An expiration date in the URI is the most uncritical part

  451. intosi has left

  452. intosi has joined

  453. Ge0rG

    marc: only half-serious.

  454. mrkiko has left

  455. mrkiko has joined

  456. moparisthebest

    actually is it defined what the URL looks like or contains?

  457. moparisthebest

    might be nice if the server doesn't have to actually store anything

  458. marc

    moparisthebest, no

  459. moparisthebest

    is that up to implementation then?

  460. marc

    depends on what web site do you use

  461. marc

    In my ejabberd implementation you can generate an URL with the invitation token and URI as parameter

  462. marc

    like url: "https://example.com/i/@URI@" or url: "https://example.com/i/@TOKEN@"

  463. marc

    It's up to example.com then how to display the invitation

  464. moparisthebest

    but who invents the URL ? (along with any parameters)

  465. marc

    moparisthebest, what do you mean by "invents the URL"

  466. moparisthebest

    can the URL be https://example.com/i/terrible.php?auth=thaeoutinhtneoauh&timestamp=445456456546&inviter=bob@bob.com&tons_of_other_vars=1

  467. marc

    Of course

  468. moparisthebest

    so the URL is generated by the server and is implementation defined, good

  469. marc

    It's a configuration parameter of the server

  470. Ge0rG

    moparisthebest: that's possible, but I could intercept your invitation link and manipulate the params

  471. Ge0rG

    moparisthebest: also: long links suck.

  472. marc

    +1

  473. moparisthebest

    Ge0rG, that's what the HMAC is for :P

  474. marc

    moparisthebest, and how do you verify it?

  475. Ge0rG

    moparisthebest: your server could just generate an encrypted & signed token that's passed on.

  476. moparisthebest

    the reason I ask is because I like the concept of https://modules.prosody.im/mod_http_upload_external.html

  477. moparisthebest

    so that your xmpp server and your web server don't need to talk, and you don't need to store anything

  478. moparisthebest

    they simply share a secret key and done

  479. marc

    You could do this

  480. marc

    But that's out of scope here

  481. moparisthebest

    yep excellent, just wanted to ensure you could do it :)

  482. marc

    At least in my opinion

  483. Ge0rG

    moparisthebest: the invitation token is opaque for the client and can contain anything you want.

  484. moparisthebest

    the URL you mean? that's mainly what I was getting at

  485. Ge0rG

    moparisthebest: it could be a base64-encoded zlib compressed collection of Shakespeare.

  486. daniel has joined

  487. Ge0rG

    moparisthebest: the URL should not be the primary means, if the receiver already supports xmpp: URIs

  488. moparisthebest

    ok, cool, that still works

  489. Ge0rG

    moparisthebest: and you can encode your magic token in the xmpp: URI parameter

  490. moparisthebest

    a neat stateless format might be like base64(inviter@jid\0expiration_timestamp\0hmac)

  491. Ge0rG

    marc: so the invitee client still needs to support registration failures.

  492. marc

    Ge0rG, of course

  493. Ge0rG

    marc: so technically we don't need to encode a way to reject invitation tokes on ad-hoc

  494. marc

    Ge0rG, technically not but for UX :D

  495. Ge0rG

    marc: unless you want to limit the number of tokens, which you already agreed are cheap

  496. Ge0rG

    marc: do you think there should be a limitation on the number of PARS token?

  497. uc has left

  498. marc

    Ge0rG, I don't see a reason for PARS token but maybe there are some

  499. marc

    Ge0rG, PARS tokens are not that critical I think

  500. Ge0rG

    marc: the IBR tag is a nice-to-have additional feature on top of PARS. If the server is out of invitation codes, I think it makes for a better UX to skip the ibr invitation and to fallback to plain PARS than to break the complete invitation flow

  501. marc

    Ge0rG, plain PARS is client-side PARS, right?

  502. ralphm has joined

  503. Ge0rG

    marc: no, plain PARS is PARS without ibr support

  504. Ge0rG

    marc: but server-side

  505. marc

    Ge0rG, okay... yes I thought about it. Somehow it is nice but somehow ugly

  506. marc

    The nice thing is that the inviter can still invite users

  507. Ge0rG

    C: request invite token S: is the user allowed? yes -> return PARS+IBR no -> return PARS not supported -> return error C: didn't get token? Fallback to client-side PARS

  508. marc

    The bad thing is that invitees receive different invitations

  509. Ge0rG

    marc: and I think it does not make sense to limit the number of pending PARS+IBR tokens in that scenario

  510. Ge0rG

    marc: yes, unless you limit _registrations_ as opposed to _inivtations_ :P

  511. Ge0rG

    if you don't limit invitations, all invites from a user look the same

  512. marc

    Ge0rG, yes, you get confused after 30 seconds instead of 10 seconds :p

  513. Ge0rG

    marc: I don't understand

  514. Kev has left

  515. marc

    Ge0rG, you get confused when the registration doesn't work instead of getting a different invitation

  516. Kev has joined

  517. Ge0rG

    marc: except there is no guarantee that the registration link will work

  518. blabla has joined

  519. marc

    Ge0rG, sounds like a broken system by design?

  520. Ge0rG

    marc: did you know that TCP is by definition a reliable protocol, and that you still can't rely on it?

  521. blabla has left

  522. marc

    Ge0rG, did you know that a normal user doesn't care about technical issues? ;)

  523. blabla has joined

  524. Ge0rG

    marc: what's your point?

  525. Ge0rG

    marc: "inviter out of registrations" is one of many possible reasons to reject an account registration.

  526. Ge0rG

    marc: on a sane server, no users will ever run into it

  527. marc

    An invitation token MUST work if you received one

  528. Ge0rG

    marc: what if the server went down due to a nuclear bomb?

  529. Ge0rG

    still a MUST?

  530. Ge0rG

    what if the server admin was fed up by dumb arguments and shut it down?

  531. marc

    Ge0rG, well, the server wouldn't respond in this case so it's fine I think

  532. marc

    Probably the user will blame the ISP

  533. marc

    That's fine

  534. Ge0rG

    marc: "An invitation token MUST work if you received one" - there is no way on earth to enforce that.

  535. marc

    Ge0rG, I guess you know what I mean with this statement ;)

  536. Ge0rG

    marc: especially not if you issue time-limited tokens

  537. Ge0rG

    marc: I guess you don't :P

  538. marc

    Ge0rG, time limitations are known to users from many other services

  539. Ge0rG

    marc: so you agree that it's normal for a registration not to work always?

  540. Ge0rG

    normal in the sense that users will expect this to happen, from time to time

  541. blabla has left

  542. marc

    Ge0rG, if the invitee followed the rules it shouldn't happen

  543. marc

    Ge0rG, and if the server is down for a minute if works after a minute

  544. Ge0rG

    marc: except the invitation email got greylisted for a day and the token expired. BOOM.

  545. marc

    And nobody has to generate an other token

  546. Ge0rG

    marc: another token wouldn't even help if the inviter is out of invitations :P

  547. marc

    Ge0rG, yes, but that's out of scope sorry

  548. marc

    Ge0rG, depends on your policy

  549. Ge0rG

    marc: my point is: you can't enforce in the XEP that an invitaiton token MUST always work.

  550. Ge0rG

    marc: and if you accept that truth, you can make the overall flow easier and more consistent by removing a corner case.

  551. Ge0rG

    namely the corner case where your server rejects/downgrade the invitation token because of some internal counter.

  552. marc

    Ge0rG, yes, you can not enforce it but we shouldn't introduce confusing behaviour on purpose

  553. Ge0rG

    marc: I think it's more confusing if your server returns different invitations based on how often you asked

  554. marc

    Ge0rG, yes, let's block it completely then :D

  555. Ge0rG

    marc: I think it's more confusing if your server returns different responses based on how often you asked

  556. marc

    Ge0rG, I don't agree with this statement if you throw a warning or an error or something like that

  557. blabla has left

  558. marc

    Ge0rG, and if you think that's confusing to the user if they receive different invitations you shouldn't implement client-side PARS as fallback :D

  559. marc

    +it

  560. Kev has left

  561. Ge0rG

    marc: users get confused by different UI flows, not by different URLs.

  562. marc

    Ge0rG, UI flow for client-side PARS is different because you can not create an account for some reason

  563. Ge0rG

    marc: let's assume for a moment that you MUST limit the number of new accounts invited by a given user. Then you will have one confusing UX, either on invitation token generation or on account creation. But the latter only happens if the receiver doesn't have an XMPP account yet and if other people who got invitations didn't use them.

  564. Ge0rG

    marc: you can create an account, just not with the inviter's server.

  565. marc

    Ge0rG, " if other people who got invitations didn't use them"? -> "if all other people who got invitations use them"?

  566. Ge0rG

    marc: correct

  567. marc

    Ge0rG, sounds unpredictable for the invitee to me

  568. marc

    And still you have to track the tokens after account creation

  569. marc

    Or at least some counter for a user

  570. Ge0rG

    marc: you have to anyway

  571. marc

    Ge0rG, no, just store the token. If an account is created, remove it

  572. marc

    No other information is needed

  573. zinid has left

  574. Kev has left

  575. Ge0rG

    marc: what if the account registration would trigger another limit?

  576. stefandxm has joined

  577. marc

    Ge0rG, what limit?

  578. Ge0rG

    marc: total number of registrations per day for example

  579. marc

    Ge0rG, that should be included in the account/token generation process

  580. marc

    Ge0rG, of course you can configure your service for bad UX ;)

  581. marc

    I think an account token should be considered as already registered account

  582. marc

    For the "account limitation policy"

  583. Ge0rG

    marc: I disagree

  584. Ge0rG

    marc: an account-invte token is as good as an already registered account, but a PARS+IBR token is just an option

  585. Ge0rG

    you can short-sell options

  586. blabla has left

  587. ralphm has joined

  588. marc

    Ge0rG, correct, but account invitations shouldn't be blocked by other rules once they are issued IMO

  589. Ge0rG

    marc: yes, but account invitations are created by admins anyway.

  590. marc

    Ge0rG, we're talking about account invitations+PARS ;)

  591. marc

    I think you know this ;)

  592. Ge0rG

    marc: wait a moment. I was talking about contact invitations with IBR-fallback

  593. marc

    Ge0rG, hm?

  594. marc

    IBR = account invitation

  595. Ge0rG

    marc: account-invitation = server-admin sends xmpp://newuser@server?token to make the invitee register an account

  596. Ge0rG

    marc: contact-invitation = normal user sends xmpp:inviter@server?token;ibr to allow either contact subscription or IBR

  597. marc

    Ge0rG, IBR-fallback = invitier gives invitee the possiblity to create an account even if the server doesn't allow IBR, right?

  598. Ge0rG

    marc: right

  599. Kev has joined

  600. marc

    Ge0rG, yes, we're talking about the same thing with different terms :D

  601. Ge0rG

    marc: so you are talking about IBR-fallback?

  602. Ge0rG

    a.k.a. PARS+IBR

  603. Ge0rG

    a.k.a. contact-invitation

  604. marc

    Ge0rG, yes

  605. Ge0rG

    marc: so with the contact-invitation, there are two possibilities: either the invitee already has an account or not. In the first case, obviously, there is no need to block an "account slot" for them

  606. marc

    Ge0rG, if you think client-side PARS fallback doesn't change the UI, PARS+IBR to PARS fallback (both server-side) doesn't change the UI too

  607. marc

    So we have no problem actually

  608. Ge0rG

    marc: client-side PARS fallback performs exactly the same task, just at different places.

  609. Ge0rG

    marc: server-side PARS+IBR vs PARS-only has different implications

  610. Ge0rG

    marc: I'm just saying that it's better to overissue tokens and to limit at the moment of registration, than to run out of tokens even though the ones you issued will never be used

  611. Zash

    Ge0rG: Huh, only the admin can give out invites?

  612. marc

    Ge0rG, I know and I don't think that's good :)

  613. marc

    Zash, no

  614. Ge0rG

    Zash: only the admin can give out accounts

  615. marc

    Ge0rG, afk, just tell me why we don't use a fallback from PARS+IBR to PARS when a user reaches some IBR-invitation limit

  616. Ge0rG

    marc: because IBR-invitation limits don't make sense.

  617. marc

    Ge0rG, and explain me why we should store lots of information about users just to enforce account limitation during IBR

  618. Ge0rG

    marc: because account creation is the best moment to limit account creation.

  619. marc

    Ge0rG, why?

  620. marc

    why doesn't it make sense

  621. Ge0rG

    because until an account is created, you don't know whether it will ever be

  622. marc

    Yes, if the invitee uses PARS the inviter can issue more tokens

  623. Ge0rG

    marc: so now what you can do as the inviter depends on what your invitees do. Yay.

  624. marc

    Ge0rG, if you implement the policy that way, yes

  625. Ge0rG

    marc: that's bad UX!

  626. xnyhps has left

  627. lskdjf has joined

  628. la|r|ma has left

  629. intosi has left

  630. intosi has joined

  631. Lance has joined

  632. uc has left

  633. mimi89999 has left

  634. mimi89999 has left

  635. uc has left

  636. intosi has left

  637. intosi has joined

  638. mimi89999 has joined

  639. uc has joined

  640. Lance has left

  641. mimi89999 has left

  642. mimi89999 has left

  643. uc has left

  644. mimi89999 has left

  645. uc has left

  646. uc has joined

  647. mimi89999 has joined

  648. jjrh has left

  649. lumi has joined

  650. jubalh has left

  651. marc has left

  652. ralphm has joined

  653. Holger has left

  654. sonny has left

  655. jere has joined

  656. daniel has left

  657. nyco has joined

  658. intosi has left

  659. intosi has joined

  660. jjrh has left

  661. jjrh has left

  662. @Alacer has left

  663. daniel has left

  664. Tobias has joined

  665. tux has joined

  666. Zash has left

  667. daniel has left

  668. goffi has left

  669. nyco has left

  670. intosi has left

  671. nyco has joined

  672. sonny has left

  673. sonny has left

  674. sonny has joined

  675. sonny has left

  676. sonny has joined

  677. sonny has left

  678. sonny has left

  679. lskdjf has left

  680. lskdjf has left

  681. lskdjf has left

  682. lskdjf has joined

  683. Kev has left

  684. Holger has left

  685. lskdjf has joined

  686. zinid has left

  687. ralphm has joined

  688. sezuan has left

  689. zinid has left

  690. Steve Kille has left

  691. zinid has left

  692. Steve Kille has left

  693. lskdjf has left

  694. lskdjf has joined

  695. sonny has joined

  696. arc has left

  697. arc has joined

  698. lskdjf has joined

  699. blabla has joined

  700. lskdjf has joined

  701. jubalh has joined

  702. lskdjf has left

  703. lskdjf has left

  704. lskdjf has left

  705. lskdjf has left

  706. lskdjf has left

  707. lskdjf has left

  708. Zash has left

  709. lskdjf has joined

  710. Syndace has joined

  711. Syndace has joined

  712. lskdjf has left

  713. lskdjf has left

  714. nyco has left

  715. nyco has joined

  716. Tobias has joined

  717. jubalh has left

  718. lskdjf has left

  719. jere has joined

  720. jere has joined

  721. lskdjf has left

  722. Tobias has joined

  723. lskdjf has left

  724. lskdjf has joined

  725. Tobias has left

  726. Tobias has joined

  727. Alex has left

  728. lskdjf has left

  729. Alex has joined

  730. nyco has left

  731. nyco has joined

  732. ralphm has joined

  733. jere has joined

  734. jere has joined

  735. Steve Kille has joined

  736. ralphm has left

  737. jere has left

  738. jere has joined

  739. marc

    Ge0rG, we have two options: "bad" UX for inviter or invitee

  740. Alex has left

  741. Ge0rG

    marc: that's not true. The bad UX for the invitee is inevitable

  742. Ge0rG

    marc: the good thing, it is only bad in corner cases.

  743. Zash

    Do you have like user stories written down?

  744. Ge0rG

    I'd like to write the specification down.

  745. marc

    Ge0rG, Yes, it's a corner case for both solution

  746. marc

    +s

  747. Steve Kille has left

  748. marc

    and I think for your solution additional data needs to be stored on the server

  749. Ge0rG

    marc: maybe, maybe not.

  750. sonny has joined

  751. marc

    Ge0rG, :P

  752. efrit has joined

  753. Ge0rG

    marc: you need to store a counter on the user account anyway, if you want to limit number/time

  754. marc

    Ge0rG, but that's optional

  755. Ge0rG

    and adding a counter of user-initiated IBRs is not very expensive

  756. marc

    Ge0rG, in your solution that's required

  757. Ge0rG

    marc: no, it's optional. You don't NEED to limit anything.

  758. marc

    Ge0rG, for my solution you use data which are necessary anyway

  759. Ge0rG

    marc: but your solution is limiting user behavior at the wrong end of the registration

  760. ralphm has joined

  761. Ge0rG

    marc: anyway, that doesn't matter much for the XEP. Let's move this thing forward.

  762. marc

    Ge0rG, why doesn't it matter?

  763. Ge0rG

    marc: because it is an implementation detail, mostly.

  764. Ge0rG

    marc: we still need to write an XEP

  765. marc

    Ge0rG, yes, but I would like to have an error response for such things in the ad-hoc command

  766. marc

    That's the point ;)

  767. Ge0rG

    marc: the ad-hoc command is allowed to fail for whatever reasons deemed inappropriate.

  768. Ge0rG

    marc: with standard error messages

  769. marc

    Ge0rG, oh no.. standard error messages

  770. marc

    They're not useful at all

  771. Ge0rG

    marc: but I still am convinced that it is wrong to let it fail.

  772. arc has left

  773. arc has joined

  774. lskdjf has joined

  775. Ge0rG

    So I've been writing a blog post about fighting spam today, instead of writing the invitation XEP.

  776. lskdjf has left

  777. sonny has left

  778. jcbrand has joined

  779. lskdjf has left

  780. nyco has left

  781. lskdjf has left

  782. sonny has left

  783. sonny has joined

  784. nyco has joined

  785. lskdjf has left

  786. lskdjf has left

  787. jcbrand has left

  788. jcbrand has left

  789. daniel has left

  790. daniel has left

  791. lskdjf has left

  792. daniel has left

  793. daniel has left

  794. mrkiko has left

  795. mrkiko has joined

  796. lskdjf has joined

  797. lskdjf has left

  798. lskdjf has left

  799. arc has left

  800. arc has joined

  801. jonasw has left

  802. debacle has left

  803. jere has joined

  804. ralphm has joined

  805. la|r|ma has joined

  806. ralphm has joined

  807. arc has left

  808. arc has joined

  809. goffi has joined

  810. lskdjf has left

  811. ralphm has joined

  812. jcbrand has joined

  813. jcbrand has left

  814. jcbrand has joined

  815. lskdjf has joined

  816. jcbrand has left

  817. daniel has left

  818. lskdjf has left

  819. tux has left

  820. arc has left

  821. jubalh has joined

  822. arc has joined

  823. arc has left

  824. arc has joined

  825. waqas has joined

  826. jubalh has left

  827. zinid has left

  828. arc has left

  829. arc has joined

  830. sonny has joined

  831. lskdjf has left

  832. Ge0rG has left

  833. lskdjf has joined

  834. uc has joined

  835. ralphm has joined

  836. jere has joined

  837. jere has joined

  838. arc has left

  839. arc has joined

  840. sonny has joined

  841. arc has left

  842. arc has joined

  843. uc has joined

  844. ralphm has left

  845. nyco has left

  846. nyco has joined

  847. jere has joined

  848. jere has joined

  849. Ge0rG has left

  850. daniel has left

  851. goffi has left

  852. ralphm has joined

  853. Holger has left

  854. lskdjf has joined

  855. lskdjf has left

  856. lskdjf has left

  857. daniel has left

  858. Ge0rG has joined

  859. daniel has joined

  860. jubalh has joined

  861. ralphm has left

  862. jubalh has left

  863. moparisthebest has joined

  864. Holger has left

  865. jjrh has left

  866. marc has left

  867. arc has left

  868. arc has joined

  869. marc has left

  870. Kev has joined

  871. lumi has joined

  872. edhelas has left

  873. edhelas has joined

  874. lumi has joined

  875. sonny has joined

  876. sonny has joined

  877. sonny has left

  878. sonny has joined

  879. lskdjf has joined

  880. lskdjf has left

  881. jere has joined

  882. jubalh has joined

  883. sonny has joined

  884. sonny has joined

  885. Kev has left

  886. sonny has left

  887. sonny has joined

  888. sonny has left

  889. sonny has joined

  890. lskdjf has left

  891. lskdjf has left

  892. sonny has left

  893. sonny has joined

  894. Ge0rG has left

  895. edhelas

    I'm planning to do another PR on 0060 in the upcoming days

  896. sonny has joined

  897. edhelas

    to expose the access_model tag in the metadata

  898. arc has left

  899. arc has joined

  900. jere has joined

  901. arc has left

  902. arc has joined

  903. sonny has left

  904. sonny has joined

  905. arc has left

  906. arc has joined

  907. Ge0rG has left

  908. lovetox has left

  909. arc has left

  910. arc has joined

  911. tux has left

  912. arc has left

  913. arc has joined

  914. Holger has left

  915. arc has left

  916. arc has joined

  917. Ge0rG has left

  918. arc has left

  919. arc has joined

  920. jjrh has left

  921. Ge0rG has left

  922. jere has left

  923. jere has joined