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