XSF logo XSF Discussion - 2017-12-12


  1. zinid has joined
  2. sonny has left
  3. sonny has joined
  4. sonny has joined
  5. sonny has joined
  6. sonny has left
  7. sonny has joined
  8. uc has joined
  9. efrit has joined
  10. zinid has left
  11. sonny has left
  12. sonny has left
  13. sonny has left
  14. jere has joined
  15. daniel has left
  16. daniel has joined
  17. jere has joined
  18. sonny has joined
  19. sonny has left
  20. uc has joined
  21. zinid has joined
  22. sonny has joined
  23. Holger has left
  24. sonny has left
  25. sonny has left
  26. sonny has left
  27. sonny has joined
  28. sonny has left
  29. sonny has joined
  30. lskdjf has left
  31. sonny has left
  32. uc has joined
  33. sonny has joined
  34. daniel has left
  35. daniel has joined
  36. lskdjf has joined
  37. lskdjf has left
  38. arc has left
  39. arc has joined
  40. zinid has left
  41. sonny has joined
  42. sonny has joined
  43. sonny has left
  44. sonny has joined
  45. sonny has joined
  46. sonny has joined
  47. arc has left
  48. lumi has left
  49. arc has joined
  50. lskdjf has left
  51. lskdjf has left
  52. uc has joined
  53. lskdjf has joined
  54. uc has joined
  55. Zash has left
  56. lskdjf has left
  57. lskdjf has joined
  58. lskdjf has joined
  59. lskdjf has joined
  60. lskdjf has left
  61. lskdjf has joined
  62. uc has joined
  63. lskdjf has left
  64. lskdjf has joined
  65. uc has joined
  66. goffi has left
  67. Holger has left
  68. lskdjf has left
  69. arc has left
  70. arc has joined
  71. arc has left
  72. Zash has joined
  73. arc has joined
  74. Tobias has joined
  75. daniel has left
  76. daniel has joined
  77. daniel has left
  78. daniel has joined
  79. matlag has left
  80. zinid has joined
  81. Tobias has joined
  82. SamWhited has left
  83. zinid has left
  84. jjrh has left
  85. jjrh has left
  86. jjrh has left
  87. jjrh has left
  88. daniel has left
  89. daniel has joined
  90. jjrh has left
  91. Guus has left
  92. Guus has joined
  93. daniel has left
  94. daniel has joined
  95. daniel has left
  96. daniel has joined
  97. zinid has joined
  98. la|r|ma has joined
  99. jjrh has left
  100. Guus has left
  101. daniel has left
  102. daniel has joined
  103. zinid has left
  104. sonny has joined
  105. jjrh has left
  106. andrey.g has joined
  107. daniel has left
  108. daniel has joined
  109. Zash has left
  110. daniel has left
  111. daniel has joined
  112. Zash has joined
  113. efrit has left
  114. efrit has joined
  115. jere has left
  116. jere has joined
  117. daniel has left
  118. daniel has joined
  119. daniel has left
  120. daniel has joined
  121. zinid has joined
  122. daniel has left
  123. daniel has joined
  124. zinid has left
  125. daniel has left
  126. daniel has joined
  127. mrkiko has joined
  128. daniel has left
  129. daniel has joined
  130. daniel has left
  131. daniel has joined
  132. zinid has joined
  133. Kev has left
  134. SamWhited has joined
  135. SamWhited has joined
  136. daniel has left
  137. daniel has joined
  138. daniel has left
  139. daniel has joined
  140. SamWhited has joined
  141. zinid has left
  142. zinid has joined
  143. sonny has joined
  144. zinid has left
  145. daniel has left
  146. daniel has joined
  147. efrit has left
  148. daniel has left
  149. daniel has joined
  150. SamWhited has left
  151. SamWhited has left
  152. daniel has left
  153. daniel has joined
  154. daniel has left
  155. daniel has joined
  156. jere has joined
  157. la|r|ma has joined
  158. SamWhited has left
  159. SamWhited has left
  160. SamWhited has joined
  161. zinid has joined
  162. Guus has joined
  163. uc has joined
  164. uc has joined
  165. la|r|ma has left
  166. zinid has left
  167. arc has left
  168. arc has joined
  169. SouL has left
  170. arc has left
  171. arc has joined
  172. @Alacer has left
  173. @Alacer has joined
  174. andrey.g has joined
  175. andrey.g has joined
  176. andrey.g has joined
  177. andrey.g has joined
  178. andrey.g has joined
  179. andrey.g has joined
  180. sonny has joined
  181. daniel has left
  182. andrey.g has joined
  183. daniel has joined
  184. arc has left
  185. @Alacer has left
  186. arc has joined
  187. @Alacer has joined
  188. zinid has joined
  189. andrey.g has joined
  190. SouL has left
  191. andrey.g has joined
  192. andrey.g has joined
  193. arc has left
  194. arc has joined
  195. jmpman has joined
  196. andrey.g has joined
  197. andrey.g has joined
  198. andrey.g has joined
  199. andrey.g has joined
  200. @Alacer has left
  201. @Alacer has joined
  202. andrey.g has joined
  203. andrey.g has joined
  204. Guus has left
  205. Guus has joined
  206. andrey.g has joined
  207. andrey.g has joined
  208. andrey.g has joined
  209. andrey.g has joined
  210. arc has left
  211. arc has joined
  212. moparisthebest has joined
  213. andrey.g has joined
  214. andrey.g has joined
  215. Guus has left
  216. andrey.g has joined
  217. andrey.g has joined
  218. la|r|ma has joined
  219. daniel has left
  220. andrey.g has joined
  221. andrey.g has joined
  222. andrey.g has joined
  223. andrey.g has joined
  224. sonny has joined
  225. tim@boese-ban.de has joined
  226. andrey.g has joined
  227. @Alacer has left
  228. @Alacer has joined
  229. andrey.g has joined
  230. daniel has left
  231. daniel has left
  232. Guus has joined
  233. mimi89999 has joined
  234. uc has joined
  235. arc has left
  236. arc has joined
  237. andrey.g has joined
  238. andrey.g has joined
  239. sezuan has left
  240. andrey.g has joined
  241. waqas has joined
  242. andrey.g has joined
  243. andrey.g has joined
  244. waqas has left
  245. andrey.g has joined
  246. arc has left
  247. arc has joined
  248. andrey.g has joined
  249. andrey.g has joined
  250. andrey.g has joined
  251. jonasw has left
  252. andrey.g has joined
  253. andrey.g has joined
  254. Guus has left
  255. Guus has joined
  256. andrey.g has joined
  257. zinid has left
  258. andrey.g has joined
  259. daniel has left
  260. arc has left
  261. arc has joined
  262. andrey.g has joined
  263. andrey.g has joined
  264. daniel has left
  265. andrey.g has joined
  266. andrey.g has joined
  267. jcbrand has joined
  268. daniel has left
  269. Guus has left
  270. daniel has left
  271. andrey.g has joined
  272. andrey.g has joined
  273. Kev has left
  274. andrey.g has joined
  275. andrey.g has joined
  276. andrey.g has joined
  277. andrey.g has joined
  278. @Alacer has left
  279. @Alacer has joined
  280. andrey.g has joined
  281. Steve Kille has left
  282. Steve Kille has left
  283. Steve Kille has joined
  284. daniel has left
  285. daniel has left
  286. daniel has joined
  287. marc has joined
  288. goffi has joined
  289. @Alacer has left
  290. @Alacer has joined
  291. Ge0rG has left
  292. Kev has left
  293. Ge0rG has left
  294. SouL has left
  295. daniel has left
  296. Guus has joined
  297. Ge0rG has left
  298. @Alacer has left
  299. lskdjf has joined
  300. @Alacer has joined
  301. sonny has joined
  302. zinid has left
  303. Ge0rG has left
  304. Ge0rG has left
  305. daniel has left
  306. ralphm has left
  307. daniel has left
  308. tux has joined
  309. daniel has left
  310. jere has joined
  311. Syndace has left
  312. Syndace has joined
  313. zinid has left
  314. zinid has joined
  315. lumi has joined
  316. Ge0rG has left
  317. ralphm has joined
  318. debacle has joined
  319. zinid has left
  320. daniel has left
  321. daniel has joined
  322. efrit has joined
  323. @Alacer has left
  324. @Alacer has joined
  325. jere has left
  326. lskdjf has joined
  327. zinid has left
  328. jere has joined
  329. blabla has joined
  330. jere has left
  331. jere has joined
  332. efrit has left
  333. jere has left
  334. jere has joined
  335. efrit has joined
  336. Guus has left
  337. daniel has left
  338. daniel has joined
  339. jere has left
  340. jere has joined
  341. Guus has left
  342. zinid has left
  343. jabberatdemo has joined
  344. jabberatdemo has left
  345. daniel has left
  346. la|r|ma has joined
  347. la|r|ma has left
  348. la|r|ma has joined
  349. Guus has left
  350. la|r|ma has left
  351. la|r|ma has joined
  352. Syndace has left
  353. Syndace has joined
  354. Guus has left
  355. zinid has left
  356. Guus has left
  357. jere has left
  358. jere has joined
  359. Guus has left
  360. la|r|ma has left
  361. intosi has joined
  362. valo has joined
  363. Alex has joined
  364. jere has left
  365. jere has joined
  366. ralphm has left
  367. Alex has left
  368. Holger has left
  369. ralphm has joined
  370. SouL has left
  371. efrit has left
  372. zinid has left
  373. efrit has joined
  374. Kev has joined
  375. efrit has left
  376. efrit has joined
  377. sonny has joined
  378. lskdjf has joined
  379. Alex has joined
  380. Guus has left
  381. efrit has left
  382. ralphm has joined
  383. efrit has joined
  384. Kev has left
  385. Kev has joined
  386. jmpman has left
  387. jmpman has joined
  388. Guus has left
  389. zinid has left
  390. sonny has left
  391. lskdjf has left
  392. jubalh has joined
  393. waqas has joined
  394. waqas has left
  395. goffi hi there, can I have clarification on #publish-options? As far as I remember, it was an way to configure a node on creation without having to create then configure. But it seems to have changed and to be way to do per-item configuration. I haven't had chance to follow all discussion on @standard, so a summary would be much appreciated, thanks
  396. daniel goffi: it can be both
  397. daniel The fields are registered. And each field defines if it's is a precondition (= node configuration on publish and enforcement) or an override
  398. goffi But this are 2 different features. Where the fields are registered (and which fields are registered?) ?
  399. goffi the XEP is not clear at all about that. The examples only show publication with items, and there is not notion of node creation.
  400. Zash I don't think autocreation and configuration on publish is a thing that's specified
  401. goffi I though it was #publish-option (and it was not specified indeed, just in example as far as I remember, like many Pubsub features unfortunately)
  402. Holger It was all totally underspecified before, but the wording has been clarified and things seem clear to me now: https://xmpp.org/extensions/xep-0060.html#publisher-publish-options
  403. Holger Zash: "If the node does not exist and the service supports the "auto-create" feature, then the service shall auto-create the node with default configuration in all respects except those specified in the preconditions, and the publish succeeds."
  404. goffi yes that how it is implemented in SàT Pubsub
  405. goffi but "Each field MUST specify whether it defines METADATA to be attached to the item, a per-item OVERRIDE of the node configuration, or a PRECONDITION to be checked against the node configuration. " is really confusing, which metadata can we attach?
  406. goffi how to override item, as the text only mention precondition or node configuration on auto-create
  407. goffi I think I'll write on @standard to discuss that, because it needs to be extremly clear and it is definetely not at the moment.
  408. Holger goffi: Right now there's only a single registered option (access_model), and it's specified to be a PRECONDITION. So OVERRIDE/METADATA are only theoretical options as long as no field is registered with that behavior.
  409. Zash Holger: Is that so?
  410. Holger Zash: Sure?
  411. goffi Holger: where it is registered ? How can I check it ?
  412. goffi I've implemented per-item overriding for years, and I'm since willing to propose a protoXEP for that (no time so far), so I'm willing to know if current publish-option can do it (I've explained how it's done in SàT pubsub at https://www.goffi.org/blog/goffi/S%C3%A0T_DOTCLEAR_IMPORT_BLOG_default_goffi_69%3A2012%2F06%2F24%2FFine-access-tuning-for-PubSub)
  413. Zash goffi: I would be happier if it was split in three
  414. Holger goffi: https://xmpp.org/extensions/xep-0060.html#registrar-formtypes-publish
  415. Holger goffi: Huh you implemented it. What's the use case?
  416. Holger goffi: My suggestion would've been to ditch OVERRIDE/METADATA. And if someone needs that feature, re-add it using different syntax.
  417. goffi Zash: what do you mean split in three ?
  418. Holger goffi: Isn't the implementation a great PITA when it comes to RSM / MAM access, for example?
  419. goffi Holger: blog post restricted to some people, similar to Google circles (even if it was done before)
  420. Zash Three forms, where the form decides what tge fields do, not some registry
  421. goffi Zash: ah yes, I think it would be better indeed, and in a separate XEP
  422. Holger goffi: https://github.com/xsf/xeps/pull/556
  423. goffi I need to check SàT Pubsub code, I'm not sure of the behaviour if the node exists (I think the options are just ignored, which is not compliant which current XEP state)
  424. Zash goffi: You have my support if you were to draft one
  425. efrit has left
  426. goffi Zash: I will, but it will take time, I am already drowning in work
  427. Alex has left
  428. Ge0rG Yeah, reading that section of 0060 made my head explode. And I'm used to reading protocol specs.
  429. jonasw I think we need a very diligent copy editor, ideally english mother tongue, who goes over those monsters like XEP-0060 and edits everything which is remotely unclear, while being in constant feedback with the community and council
  430. goffi daniel: OK it's a good thing to remove override, and probably it would be nice to remove metadata too, only keeping precondition and config setting.
  431. daniel i don't care very much for metadata either
  432. Zash jonasw: we were going to split '60 into smaller pieces
  433. goffi not sure if there is a use case on a per-item basis for metadata. Override there is definitely, but should be separate feature
  434. daniel i'd be fine with removing it for now and reintroducing it as a seperate form later if someone needs it
  435. edhelas daniel I do care of metadata actually
  436. goffi edhelas: on a per-item basis ?
  437. edhelas ah for items, meh, no
  438. edhelas sorry, misunderstanding
  439. goffi for node it's needed I think we all agree on that
  440. zinid has left
  441. zinid > ideally english mother tongue They tend to use some rare wording which is only possible to translate with a dictionary 🙂
  442. daniel removing METADATA entirly changes the wording *a lot*. I'd rather only do that if we agree that this is the right thing
  443. Holger agrees ;-)
  444. jonasw if we remove it in a way so that we can bring it back in an addendum && we don’t have any depending XEPs currently, I don’t see any issue.
  445. goffi agrees too
  446. edhelas daniel in which cases you want to remove metadata ? I'm a bit lost
  447. Ge0rG I want that whole section burned. It doesn't make any sense.
  448. daniel edhelas, publish-options. we are talking about publish-options
  449. Ge0rG Removing metadata and override from the XEP would suffice for me, though.
  450. daniel removing metadata and override and maybe the ability to register additional fields would make the wording a lot more straight forward
  451. edhelas yeah registering fields could be quite nice and make it more flexible
  452. sonny has left
  453. Holger Nah. No registering.
  454. goffi registering is not useful there, and bring a lot of complications
  455. jonasw no registering, but honoring <required/> so that implementations know when an option is critical?
  456. Holger Only node config preconditions. That makes it straightforward to understand and implement.
  457. jonasw that seems like a good compromise and allows later XEPs to extend things
  458. jonasw ah yes
  459. Holger And we make it work for all node config options in one go.l
  460. Holger jonasw: <required/> what?
  461. goffi that would make my current implementation nearly compliant, just need to check the precondition
  462. jonasw Holger, publish-options is a Data Form, right?
  463. Holger Yes.
  464. jonasw Data Forms specifies the <required/> child for fields
  465. jonasw users of publish-options could make it clear that a field MUST be understood or the request MUST be rejected with that
  466. jonasw while other unknown fields may be safely discarded
  467. Holger The wording already does that.
  468. Holger Uh.
  469. jonasw just an idea to open the venue for future extensions without making things too complicated with a registry etc.
  470. goffi Can't we ignore unknow fields if it's not a configuration option ? Else that would make it difficult to extend (new options specified in later XEP will not be usable on old implementations)
  471. daniel goffi, no
  472. goffi daniel: why ?
  473. Holger Well my suggestion was to reject anything that's not a config option.
  474. daniel because you have to rely on the fact that they are checked
  475. zinid unknown fields in practice will mean a client bug in 99% cases
  476. jonasw Holger, yeah, tbh, I was still thinking about the other use-cases, not Node Config overrides
  477. goffi but if it's not a configuration options ?
  478. Holger goffi: What should the publish option do then?
  479. goffi zinid: no, it can means a new options introduced in new XEP and not handled in current server
  480. zinid goffi, then it's fine for the server to return error, so a client doesn't expect the option takes effect
  481. goffi Holger: create node with right config, reject node with bad config, and let in place for unknow config options
  482. daniel how about something simple as https://gultsch.de/files/xep-0060.html#publisher-publish-options
  483. daniel exact wording tbd
  484. goffi daniel: happied with that, but worried about unknow fields
  485. daniel why?
  486. Holger goffi: You can't just ignore unknown options because clients probably want to rely on them being set. See the bookmarks XEP, for example.
  487. Holger goffi: If anything, you could go for jonasw's route and let the client specify whether the option is <required/>. But meh.
  488. zinid Holger, not to mention that you will get fancy "bug reports" like "I set this knob but it doesn't work!"
  489. daniel if you ever want to do something else just define your own form
  490. Holger goffi: I don't quite see the use case of specifying a publish option without caring whether it actually works.
  491. Holger zinid: Exactly.
  492. moparisthebest what if you just specify a new XEP 'pubsub-lite' in the time honored XSF tradition of replacing complicated XEPs with simpler ones that everyone actually wants?
  493. Ge0rG moparisthebest: I'm already waiting for MUC to replace MIX in five years :D
  494. Zash Ge0rG: Wow, aren't you the optimist
  495. zinid MUC to replace MIX?
  496. goffi Holger: zinid: daniel: use case => options "serial_ids" to have ids in series instead of uuids. If present I want it to be set I specify in publish option. A server is not managing it, my publish will fail with current wording.
  497. Ge0rG zinid: yes, because MIX is too complicated.
  498. zinid Ge0rG, ah, agreed
  499. zinid no way I implement it in ejabberd
  500. daniel goffi, it will already fail with the current wording
  501. daniel because serial_ids is not registered
  502. Zash MIX looks unlikely to be implemented in Prosody either atm
  503. daniel you can not just invent shit without registering it
  504. goffi daniel: yes I didn't say the opposite, I just say the current wording and one in patch are not future-proof
  505. zinid goffi, can't you just request the form to check what fields are supported?
  506. goffi zinid: ah yes good point
  507. daniel goffi, just create your own form. whats the problem?
  508. goffi zinid: but need one more request
  509. Holger goffi: And it buys you a clear spec with defined behavior.
  510. zinid goffi, ah, you client developers are afraid of requests 😀
  511. daniel create a form name it publish-sequential-enforcing-agency-visual-studio-powered
  512. goffi :)
  513. zinid I"m always forgetting this 😉
  514. daniel and be done
  515. goffi OK I'm convinced now, I can just request the form
  516. Guus has left
  517. goffi so I'm fully in for daniel's patch
  518. Ge0rG Do we need to bump the namespace version?
  519. daniel no
  520. zinid YES
  521. zinid 😀
  522. edhelas just bump by .05 and we're good
  523. daniel anyone has any suggestions on improving the wording based on https://gultsch.de/files/xep-0060.html#publisher-publish-options
  524. jonasw daniel, wfm
  525. arc has left
  526. arc has joined
  527. daniel Ge0rG, is that wording fine with you?
  528. daniel you complained about the entire section before
  529. Ge0rG daniel: no, it's not fine. You are introducing the term PRECONDITION and kind of implicitly define it in that sentence. It works if you already know what a PRECONDITION is, but otherwise you stumble upon the CAPITAL LETTERS
  530. Holger Hah, after pressing 'reload', I actually see the changes :-) Browser caches yay.
  531. daniel Ge0rG, suggestions for improvments?
  532. lskdjf has left
  533. daniel using lower case?
  534. goffi yes lower cae
  535. goffi case
  536. Ge0rG daniel: I'm trying to come up with a better wording, bear with me.
  537. sonny has joined
  538. lskdjf has left
  539. jjrh has left
  540. zinid argh, I don't understand
  541. zinid does this precondition magic means publish-options should borrow all options from node-config?
  542. Holger zinid: Yes.
  543. daniel zinid: yes
  544. zinid has left
  545. zinid Holger, ah, so we have a bug in ejabberd 🙂
  546. Holger zinid: We don't comply with the version suggested a few minutes ago on gultsch.de.
  547. Holger zinid: Not sure I'd call that a bug :-)
  548. Ge0rG daniel: maybe the following: > Each form field denotes a precondition to publishing the request. A pub-sub service advertising support for publishing options MUST check each precondition field against the node configuration of the same name, and it MUST reject the publication upon encountering unknown fields.
  549. Holger zinid: We do comply with the current XEP-0060 wording.
  550. sonny has left
  551. zinid Holger, well I just didn't know what exactly Daniel has added 🙂
  552. Guus has left
  553. Holger zinid: Ah ok. This exactly is the change he's suggesting.
  554. daniel `<F5>`
  555. Holger zinid: Currently 0060 says that 'access_model' is the only valid publish option.
  556. zinid Holger, yes, yes I got it 😀
  557. Holger daniel: Looks good to me.
  558. sonny has joined
  559. sonny has left
  560. goffi daniel: patch put aside, I didn't get you're "16:58][daniel] goffi, just create your own form. whats the problem?", what were you suggesing actually? It's a configuration option, I can't put this in a random form.
  561. lskdjf has left
  562. lskdjf has left
  563. lskdjf has left
  564. lskdjf has joined
  565. daniel goffi, well currently (as published by the XSF) you'd have to register a precondition with the registrar. i'm suggesting instead of doing that just define a form
  566. daniel like send a PR to xep60
  567. sonny has left
  568. daniel either way you'd have to go through the xsf
  569. goffi daniel: I'll sure do for the per-item overridding, and other feature I'm willing to standardize, but serial_ids would just be a setting like any service would add, I think it's a bit overkill to create form or go through XSF for every single config option (in the particular case of serial_ids, it could be generally useful so it may make sense)
  570. daniel > I think it's a bit overkill to create form or go through XSF for every single config option well that's how xep60 works in that regard. none of my PRs change that
  571. jere has joined
  572. sonny has left
  573. daniel i don't understand what exactly it is you are trying to do but either you expect a certain reaction from the server then you have to specify it anyway or you don't in which case just don't use publish-options
  574. Ge0rG Maybe it is METADATA?
  575. Ge0rG marc: so where are we regarding account-invitation?
  576. goffi daniel: I'm willing to specify node configuration atomically on creation, and publish-option is exactly what I need for that. I was worrying abount new options or vendor specific options, but as zinid rightly said I can request node configuration first, so it's alright.
  577. sonny has joined
  578. sonny has joined
  579. jjrh has left
  580. sonny has joined
  581. marc Ge0rG, if we do not need fancy feature like token revocation I would proceed with my initial approach and add server-side PARS
  582. Ge0rG marc: you could have an ad-hoc command to revoke a token :P
  583. jjrh has left
  584. marc Ge0rG, of course :)
  585. Ge0rG marc: do you want me to write the XEP or to criticize it once you've written? :P
  586. marc But I think that's too complex and could be added later
  587. Ge0rG marc: yeah, revocation is out-of-scope
  588. goffi and XEP-0060 doesn't request to register any single config option by the way (which is a good thing)
  589. Ge0rG marc: I think we have two user stories: "roster invitation with potential account creation" and "explicit account invitation". I think they should have separate ad-hoc commands, but can share wire format.
  590. marc Ge0rG, I agree with the first part
  591. marc Not sure if it makes sense to use different commands
  592. marc We could just change the data form
  593. marc If the latter is also possible
  594. Ge0rG marc: ah, right.
  595. Ge0rG marc: I remember now.
  596. Ge0rG marc: but then as an admin, you can't create a one-click roster invitation.
  597. marc Ge0rG, why?
  598. tim@boese-ban.de has left
  599. jjrh has left
  600. Ge0rG marc: because you always need to send back the JID entry form.
  601. marc Oh, *one-click* is the keyword here
  602. zinid has left
  603. jjrh has left
  604. Ge0rG marc: so maybe having separate ad-hoc commands is more useful after all.
  605. Alex has joined
  606. Ge0rG "Send invitation" for mortals, "Send account invitation" for admins
  607. marc Ge0rG, and you don't like the idea to provide the inviter name?
  608. jabberatdemo has joined
  609. Ge0rG marc: no, for two reasons: a) it is hard to validate independently and b) it's adding complexity to the process
  610. Ge0rG marc: I could send you an invitation that reads "Daniel Gultsch invited you to ..."
  611. marc Ge0rG, but it makes the invitation more personal :D
  612. marc Ge0rG, of course you can
  613. Ge0rG marc: you are sending a link to somebody. Make the message containing that link more personal.
  614. marc xmpp:romeo@montague.net?roster;preauth=1tMFqYDdKhfe2pwp;name=Romeo+Montague
  615. marc a) is not a good argument anymore ;)
  616. Ge0rG marc: xmpp:romeo@montague.net?roster;preauth=1tMFqYDdKhfe2pwp;name=Tybalt+Capulet
  617. Ge0rG marc: what now?
  618. marc Ge0rG, that's an example of your PARS XEP
  619. marc that's the point ;)
  620. Ge0rG marc: that's been almost a year :P
  621. marc Ge0rG, :P
  622. marc Ge0rG, but I'm okay with it, let's remove the possiblity to provide the inviter name
  623. marc But I would like to have nice admin options then :p
  624. Ge0rG marc: also, see §5.4
  625. marc Ge0rG, I know
  626. marc Ge0rG, but I could copy 5.4 into the new XEP ;)
  627. Ge0rG I can't link to §5.4 because somebody f***ed up the anchor. Bummer.
  628. Ge0rG marc: technically, it is okay to have an optional name parameter in the xmpp: URI, but it shouldn't require the inviter to input text
  629. Ge0rG I think we need some notion of "screen name", maybe stored in account vcard, and used as the default MUC nickname and for such invitations
  630. marc Ge0rG, I wouldn't store it into the URI but yeah
  631. Kev has left
  632. marc Ge0rG, "screen name" independent of this XEP?
  633. Ge0rG marc: yes
  634. Ge0rG marc: one day, I'll change yaxim new account creation to ask for a screenname, auto-generate a slugified JID from that and going with a secure auto-created password
  635. marc Ge0rG, there is a nickname field in vcard, isn't it?
  636. Ge0rG marc: I'm not sure screen name == nickname or rather real name
  637. Ge0rG maybe something in between.
  638. Ge0rG marc: so if you enter "Crazy Batshit" as your screenname, it would suggest "crazy.batshit@yax.im" as your JID, and fall back to "crazy.batshit.5632@yax.im" if the former is already registered.
  639. marc Ge0rG, sounds like a good idea
  640. Ge0rG marc: of course :P
  641. Ge0rG marc: I'm obsessed with Easy XMPP for over a year now.
  642. jonasw how does twitter do that?
  643. marc Ge0rG, hopefully easy-invitation will be rolled-out in the near future
  644. marc Ge0rG, I'm okay with two commands: user-invitation and "account-creation"
  645. Guus has left
  646. @Alacer has left
  647. marc user-invitation allows PARS or account creation with one click
  648. jabberatdemo has left
  649. marc account-creation is for admins with some options to generate an account for somebody
  650. marc admin or other privileged pro-users
  651. jonasw isn’t there an account creation adhoc already?
  652. Ge0rG marc: user-invitation --> `xmpp:georg@yax.im?preauth=FOOBAR;ibr` --> PARS or account registration account-creation --> form(username) --> `xmpp://username@server?preauth=FOOBAR`
  653. Ge0rG jonasw: yes, but there you must pre-set a password
  654. jonasw ah ok
  655. Ge0rG jonasw: we want to have one-click account setup for the invitee
  656. marc Ge0rG, I wouldn't make username required for account-creation but yeah looks good to me
  657. intosi has left
  658. marc And probably we need an appropriate URI action parameter
  659. marc Not sure if 'register' or 'roster' should be used
  660. marc Or something like 'invite'
  661. Ge0rG marc: hm. If you don't need a pre-defined jid for account creation, you can fallback to the PARS URI as well
  662. Ge0rG marc: https://xmpp.org/registrar/querytypes.html#register
  663. Ge0rG marc: so it would be `xmpp://username@server?register;preauth=FOOBAR`
  664. marc Ge0rG, yeah but maybe you have more options on account-creation and it doesn't cost anything to make this field optional
  665. marc Ge0rG, yes, for account-creation ?register make sense
  666. marc Ge0rG, not sure if it makes sense for PARS
  667. marc because it doesn't lead necessarily to account creation
  668. Ge0rG marc: it doesn't.
  669. marc Ge0rG, yes :)
  670. Guus has left
  671. marc But preauth is not a good action name IMO
  672. Ge0rG marc: I'd leave away the action name from PARS links for brevity.
  673. Ge0rG marc: there are actions for "roster" and "subscribe". Both are vaguely wrong.
  674. sezuan has left
  675. sezuan has joined
  676. marc Ge0rG, I know but 'preauth' could be anything
  677. marc And to be compatible with other action names I would like to use an other name
  678. marc And actually action name don't have a value
  679. marc +s
  680. Ge0rG marc: https://mail.jabber.org/pipermail/standards/2016-June/031138.html
  681. marc Ge0rG, Nobody suggested to use an action name with value nor the name "preauth"
  682. Ge0rG marc: preauth is not an action, it's a query parameter.
  683. marc Ge0rG, and what's the action? nothing?
  684. jcbrand has left
  685. Ge0rG marc: yes
  686. jcbrand has joined
  687. marc That's not better in my opinion :)
  688. marc I would prefer something like ?invite;preauth=...
  689. marc Or ?invite;token=...
  690. marc If not even using ?roster
  691. marc Which makes sense for PARS-only IMO
  692. jonasw is this bikeshedding or actual protocol discussion?
  693. Ge0rG marc: please respond to my mail from a year ago.
  694. jonasw If marc doesn’t have archives on his local machine, forging an email which is in fact a reply to that will be massively tricky :)
  695. Ge0rG marc: technically, the correct format for a query-less URI would be `xmpp:georg@yax.im?;preauth=FOOBAR`
  696. Tobias has joined
  697. Ge0rG jonasw: I can bounce my original mail, allowing to respond properly.
  698. marc Ge0rG, why is this URI query-less?
  699. marc preauth is part of the query component
  700. Lance has joined
  701. Ge0rG Sorry, "action-less"
  702. Ge0rG marc: I care more about short URIs and small QR codes.
  703. Ge0rG I'm sure somebody from Council will -1 me on that protocol violation, one day.
  704. marc Ge0rG, a few char more or less...
  705. jonasw isn’t that all just conventions
  706. jcbrand has left
  707. jonasw isn’t that all just convention?
  708. marc +s
  709. Ge0rG jonasw: yeah
  710. Ge0rG marc: did you know there are some email clients that break links longer than 72 characters?
  711. jonasw hides in shame
  712. Ge0rG marc: if you are marc_the_nice_guy@jabber.some-important-domain.com and have a long PARS token, you might be out of luck already.
  713. Ge0rG There's a reason why my XMPP service is yax.im :P
  714. marc Ge0rG, tbh no and I wouldn't care about it ^^
  715. Ge0rG marc: why do you care about the right query action, then?
  716. marc Ge0rG, because there is some sort of system for the XMPP URIs and we shouldn't break it IMO
  717. Ge0rG marc: it's already broken.
  718. marc Ge0rG, because of your XEP?
  719. Ge0rG marc: no, before that. I've written about it being broken. Nobody cared.
  720. marc Ge0rG, so let's care from now on ;)
  721. moparisthebest so ejabberd guys, seems like it could be vulnerable to https://robotattack.org/ depending on ciphers chosen, I tested conversations.im and it is safe because it only supports PFS ciphers
  722. Ge0rG marc: did you read my mail?
  723. moparisthebest erlang is specifically called out as being vulnerable fyi
  724. marc Ge0rG, https://mail.jabber.org/pipermail/standards/2016-June/031138.html this one?
  725. Ge0rG marc: yeah
  726. marc Ge0rG, I'll read it later.. I hope it's worth ;)
  727. Ge0rG marc: Good. We can continue the discussion afterwards, then. Or tomorro.
  728. Ge0rG marc: Good. We can continue the discussion afterwards, then. Or tomorrow.
  729. jonasw lolwtf, tls is still doing the broken PKCS padding?
  730. jonasw I thought this was just some funny anecdote in the lectures
  731. moparisthebest jonasw, nah it always comes back to bite everyone :P
  732. moparisthebest who's ejabberd dev in here, zinid ?
  733. jonasw Holger, too
  734. Ge0rG marc: but it's good that you see the same problems I encountered. You are on the right track ;)
  735. jere has left
  736. jere has joined
  737. zinid moparisthebest, ejabberd doesn't use erlang's native ssl support, it uses openssl
  738. moparisthebest oh, excellent, good to know, thanks zinid
  739. zinid and I'm not sure what this attack is about, I'm not a cryptobitch
  740. moparisthebest yea no need to get bogged down in details, just should be concerned if you are vulnerable or not
  741. jonasw TL;DR: they managed to sign something using facebooks SSL private key they supposedly stole. game over.
  742. zinid what's the point in all this TLS stuff, if vulnerabilites are being found every month
  743. zinid only leads to false sense of protection
  744. moparisthebest do you have something better? :P
  745. moparisthebest at least it's widely used and studied
  746. Guus has left
  747. zinid moparisthebest, well, the point is: if I didn't use TLS, I would be vulnerable to heartbleeding, where the whole system can be borked
  748. zinid not sure what I gain from using TLS in this case
  749. zinid *I wouldn't be vulnerable
  750. jonasw zinid, yeah, tls could use replacement by something much simpler. I think TLS 1.3 is on the right path with dropping support for a lot of legacy things. Not RSA though.
  751. daniel has left
  752. Ge0rG zinid: you get protection against all passive attacks, and also some protection against FSB and NSA
  753. Ge0rG I think we should standardize on Curve25519, because DJB is an awesome m*****f****r
  754. zinid Ge0rG, I think FSB and NSA already collected all vulnerabilities of openssl like that one with heartbleeding
  755. moparisthebest yea most of the TLS problems are with legacy support, they realized that and dropped all legacy from TLS 1.3
  756. Ge0rG zinid: heartbleed looked way too much like a plausible-deniability backdoor, yeah.
  757. moparisthebest but zinid it's a choice between plaintext and no protection all the time, or TLS and best protection possible most of the time
  758. Lance has left
  759. jonasw moparisthebest, although the argument that heartbleed may do more damage than plaintexting everything is plausible
  760. zinid moparisthebest, but I don't remember a single case of MITM attack, but I remember a lot of openssl fuckups
  761. zinid jonasw, exactly
  762. moparisthebest really? because some networks do MITM as normal matter of business
  763. jonasw openssl is particularly bad too
  764. moparisthebest s/networks/ISPs/
  765. moparisthebest https://forums.xfinity.com/t5/Customer-Service/Are-you-aware-Comcast-is-injecting-400-lines-of-JavaScript-into/td-p/3009551
  766. moparisthebest they even RFC'd it https://tools.ietf.org/html/rfc6108
  767. Ge0rG moparisthebest: I just was going to paste that.
  768. Ge0rG It's especially awesome for remote APIs
  769. moparisthebest I bet
  770. moparisthebest tl;dr everything should be TLS all the time, no exceptions :'(
  771. Ge0rG https://news.ycombinator.com/item?id=15892282 ;)
  772. edhelas has left
  773. Ge0rG It's nice and fair for the game to crash once you've used up 90% of your data cap.
  774. edhelas has joined
  775. Steve Kille has left
  776. Steve Kille has left
  777. Steve Kille has joined
  778. zinid moparisthebest, I mean I don't remember MITM in xmpp
  779. moparisthebest well if they do it to HTTP :)
  780. moparisthebest comcast will soon inject <message> stanzas
  781. moparisthebest UPGRADE YOUR MODEM
  782. zinid still, no a single case of xmpp mitm
  783. sezuan has left
  784. sezuan has joined
  785. Ge0rG Reminds me of the good old times of CTCP PING +++ATH0
  786. mimi89999 has joined
  787. arc has left
  788. arc has joined
  789. arc has left
  790. arc has joined
  791. Guus has left
  792. uc has joined
  793. Steve Kille has left
  794. daniel has left
  795. daniel has joined
  796. sezuan has left
  797. sezuan has joined
  798. arc has left
  799. arc has joined
  800. goffi has left
  801. Steve Kille has joined
  802. Tobias has joined
  803. jcbrand has joined
  804. Guus has left
  805. la|r|ma has joined
  806. jubalh has joined
  807. lumi has joined
  808. intosi has joined
  809. @Alacer has left
  810. @Alacer has joined
  811. lskdjf has left
  812. lskdjf has joined
  813. edhelas XML ads injection in the messages stanzas for the non-prenium accounts
  814. Ge0rG edhelas: spam filtering as a premium feature.
  815. Ge0rG The good thing about it: you can cash in from both sides
  816. edhelas there is so much business to do
  817. daniel has left
  818. Ge0rG I should do a post about spam filtering on yax.im.
  819. Zash Just figure out a way to get users to pay to view ads and you're golden
  820. daniel has joined
  821. moparisthebest to catch up to the web with all it's features we just need a XEP to send arbitrary javascript to clients so they'll execute it
  822. moparisthebest I mean we had XHTML-IM for that but now it's dead :'(
  823. daniel has left
  824. daniel has joined
  825. edhelas JS over Markdown over XMPP messages
  826. Zash RCE as a service
  827. jjrh has left
  828. intosi has left
  829. Ge0rG moparisthebest: JS is horribly inefficient to mine crypto moneys
  830. moparisthebest Ge0rG, what about WebAssembly
  831. Zash Surely there are wasm miners already running in your browser
  832. moparisthebest XEP-0400 Arbitrary WebAssembly over XMPP
  833. Ge0rG moparisthebest: what about it? Does it support OpenCL?
  834. moparisthebest probably?
  835. Guus has left
  836. arc has left
  837. arc has joined
  838. sonny has joined
  839. arc has left
  840. daniel has left
  841. matlag has left
  842. arc has joined
  843. daniel has left
  844. jjrh has left
  845. jjrh has left
  846. zinid has left
  847. ralphm has left
  848. jcbrand has left
  849. SamWhited has left
  850. debacle has left
  851. jere has joined
  852. sonny has left
  853. lskdjf has left
  854. lskdjf has joined
  855. sonny has left
  856. lovetox has joined
  857. Ge0rG marc: right, please read my email and then we agree to not use any action at all.
  858. sonny has left
  859. Alex has left
  860. marc Ge0rG, okay, give me some minutes but I'm pretty sure I don't like the concept :D
  861. sonny has left
  862. marc Ge0rG, okay, I don't see any argumentation in your mail to continue with meaningless "preauth" without action
  863. marc just because some other actions are poorly specified?
  864. Ge0rG marc: it's not meaningless. You can see from the JID that it is clearly a contact JID.
  865. Ge0rG marc: the actions are so underdefined, that yaxim just ignores the action and derives what to do from the other query parameters.
  866. jcbrand has joined
  867. Ge0rG marc: the only exception I'm using is `join` for MUCs
  868. Ge0rG if there is a `body=`, send a message, otherwise add to roster.
  869. sonny has joined
  870. sonny has joined
  871. Ge0rG marc: how does your client handle <xmpp:georg@yax.im> ?
  872. marc Ge0rG, depends
  873. Ge0rG marc: depends on what?
  874. marc If that's my account, if this contact is already in my roster
  875. Ge0rG marc: it's not your account. Now what will happen?
  876. marc Ge0rG, it probably adds you to my roster
  877. arc has left
  878. arc has joined
  879. Ge0rG marc: and what happens on <xmpp:georg@yax.im?subscribe>? On <xmpp:georg@yax.im?roster>?
  880. Ge0rG marc: what if I'm on your roster already? Should you open a chat tab instead? Or the "Edit roster item" dialog?
  881. marc Ge0rG, The same argumentation applies to your ?preauth... what if you already subsubcribed? Should you open a chat window for the user?
  882. Ge0rG marc: can we leave out PARS for a moment, please?
  883. marc Ge0rG, this has nothing to do with the 'action' concept
  884. Ge0rG marc: preauth is not an action, it's a query parameter.
  885. marc Ge0rG, yes, but what happens needs to be specified
  886. marc If you use an "action" or just query parameters
  887. Alex has joined
  888. Ge0rG marc: where?
  889. Ge0rG marc: do we want to write an Informational XEP that mandates what happens to a ?roster action if I'm already on your roster?
  890. Ge0rG marc: nobody cares enough.
  891. Ge0rG marc: See, Zash was the only one to answer to my question.
  892. marc Ge0rG, yes, nobody cares which is why all clients behave differently which sucks, right?
  893. zinid has left
  894. Ge0rG marc: there is a defined list of actions. None of them works as I would expect.
  895. Ge0rG marc: you would have to send two URIs with ?roster and ?subscribe for the full features
  896. arc has left
  897. arc has joined
  898. marc Ge0rG, yes, they don't work I know. But that's not an argument against using something like "?invite;token="
  899. marc Is it?
  900. Zash I did whatnow?
  901. Ge0rG Zash: you responded to a mail in mid 2016.
  902. Ge0rG marc: But ?invite won't be supported by any clients at all!
  903. marc Ge0rG, correct, ad-hoc commands and QR code generation too ;)
  904. marc All clients need to be adapted for user-invitation
  905. Ge0rG marc: no
  906. marc Ge0rG, okay, all except yaxim
  907. Ge0rG marc: NO!
  908. marc Ge0rG, why?
  909. Ge0rG marc: the good thing about PARS is that it's 100% backwards compatible
  910. marc Ge0rG, no client except yaxim implements PARS, correct?
  911. Ge0rG marc: right, but most clients implement roster subscription.
  912. Ge0rG marc: and some even support using xmpp: URIs for that.
  913. marc Ge0rG, what's the point here? I would like to implement user-invitation and account creation and I'm okay with that fact that clients and servers need to be adapted
  914. marc Ge0rG, I can not invite somebody with PARS and Conversations
  915. marc Because Conversations doesn't support it
  916. marc It doesn't generate a QR for me
  917. Ge0rG marc: you can invite a Conversations user with PARS, but you'll have to add them manually afterwards.
  918. marc Ge0rG, yes I know but I can not invite somebody else with Conversations
  919. Ge0rG marc: so what's your point now?
  920. marc Ge0rG, clients have to be adapted
  921. Ge0rG marc: the good thing about PARS is that only the sending client needs to be changed.
  922. marc Ge0rG, yes, that's correct
  923. marc But that's not important for me if I don't use yaxim but Gajim or Conversations or whatever
  924. marc My point: implementing an URI for this XEP in a client is not a big deal
  925. Ge0rG marc: yes. First we need two implementations, then we can make it a proper XEP, then people will follow
  926. marc Because we have to implement a lot more
  927. Ge0rG marc: I'd go with Zash's suggestion and propose xmpp:georg@yax.im?add - my client will ignore the action anyway, because the existing actions are all bad.
  928. marc And that's why I started to implement PoC in those clients... there should be a working version for all major Clients after this XEP is done
  929. Ge0rG marc: but in practice, I've chosen not to create a new action type and just to rely on the receiving client to be smart about it when encountering a JID with query parameters.
  930. marc Ge0rG, we should focus on more important things than URI definition. We can discuss the URI thing after all the complicated stuff is done
  931. marc Ge0rG, right?
  932. Ge0rG marc: right.
  933. Ge0rG marc: so how would I add the preauth token into an IBR?
  934. Ge0rG it needs to be indicated at the beginning and not as a form element.
  935. marc data form as described in my awesome XEP?
  936. marc :(
  937. marc :D
  938. Ge0rG marc: "described"? :P
  939. marc well,...
  940. marc :D
  941. marc Ge0rG, what's wrong about the form element?
  942. Ge0rG marc: how does the server know that it needs to return a form element and not just do IBR?
  943. marc Ge0rG, it returns the form element if user-invitation is supported
  944. Ge0rG marc: so now all normal IBR clients will stumble upon that?
  945. marc it also returns <required/> if IBR is allowed with token only
  946. Ge0rG has left
  947. Ge0rG marc: let's say your server supports both normal IBR and preauth, and uses preauth to add the invitee to the roster.
  948. Ge0rG marc: let's say your server supports both normal IBR and preauth, and uses preauth to add the inviter to the roster.
  949. Ge0rG marc: now everyone who wants to IBR with you gets a stupid "invite-token" dialog popup
  950. marc Ge0rG, that's correct
  951. marc But that's also a feature because I didn't have to implement much :D
  952. Ge0rG marc: it's a feature to annoy all future users because you are lazy?
  953. marc Ge0rG, no because it's a PoC
  954. Ge0rG marc: it's great for a PoC, but we need to make it a protocol now
  955. marc Ge0rG, yes, tell me your solution
  956. marc Ge0rG, probably we need to change all clients for that, right?
  957. Ge0rG marc: No?
  958. marc Ge0rG, just tell me your idea :)
  959. sonny has joined
  960. Ge0rG marc: server announces support for IBR <preauth/> in caps. client requests IBR form, receives normal form, sends registration IQ with a <preauth/> element, done.
  961. Ge0rG marc: server announces support for IBR <preauth/> in caps. client requests IBR form with a special <preauth/> marker, receives form with <preauth/>, sends registration IQ with a <preauth/> element, done.
  962. zinid has left
  963. marc Ge0rG, sounds good, you like the term preauth, hm? :D
  964. marc Ge0rG, how does this IBR form request for preauth look like?
  965. Ge0rG marc: I have put some thought into the name; it's short and it indicates what it is without depending on a certain technology
  966. lovetox has left
  967. Ge0rG <iq type='get' id='reg1' to='shakespeare.lit'> <query xmlns='jabber:iq:register'><preauth xmlns='urn:xmpp:pars:0'/></query> </iq>
  968. Ge0rG marc: I suppose this won't break IBR even if the server doesn't support PARS, and it lets the server know that the client intends to do preauth on this IBR
  969. Ge0rG so it can provide different fields in the response
  970. Ge0rG I think this is different from the typical data-forms flow which is intended for the user to enter more data. But I might be wrong and the standards@ ML will correct me.
  971. marc Ge0rG, sounds reasonable
  972. Ge0rG marc: does the above XML look good to you?
  973. marc Ge0rG, yes, except for the term "pars"
  974. Ge0rG marc: in the namespace?
  975. marc yes
  976. Ge0rG call it `paac` then, for pre-authenticated account creation :P
  977. Ge0rG marc: I'd be fine with renaming the namespace to urn:xmpp:preauth:0 as well
  978. marc haha
  979. marc :D
  980. Ge0rG Even if it would break existing yaxim installations :P
  981. arc has left
  982. marc however, 'pars' doesn't fit for account creation :)
  983. arc has joined
  984. Ge0rG marc: but pars defines the <preauth/> element, and there is nothing wrong with element reuse :P
  985. marc aahh, that sounds wrong to me ^^
  986. Ge0rG marc: let's skip over it and solve the next problem.
  987. Ge0rG we are bike shedding again.
  988. blabla has left
  989. jubalh has joined
  990. marc Ge0rG, correct... I don't see other problems that a server operator may want to limit the number of account creations per user on a time basis or something like that
  991. marc So we should think about it
  992. Ge0rG marc: those limitations can be implemented on the server, no need to change the wire format
  993. zinid has left
  994. marc Ge0rG, yes, I just don't like the idea that the server generates different types of tokens when a user hits the limit
  995. Ge0rG marc: I thought we were over that already?
  996. marc Ge0rG, it just bugs me ;)
  997. zinid has left
  998. Ge0rG marc: no, I mean that you have different ad-hoc commands for IBR and PARS tokens.
  999. marc Ge0rG, Oh, I thought we have IBR+PARS (where IBR might be disabled if the user hits a limit) and IBR-only
  1000. arc has left
  1001. marc Ge0rG, so we have PARS and IBR-only?
  1002. Ge0rG marc: we have PARS+IBR and IBR-only
  1003. marc Ge0rG, correct
  1004. marc But what happens if the user hits a limit?
  1005. Ge0rG marc: I'm not sure what the right solution would be.
  1006. marc No PARS and IBR at all?
  1007. marc Or just PARS?
  1008. Ge0rG marc: I think that sending a PARS-only token is better than no token.
  1009. Ge0rG marc: also PARS+IBR doesn't mean all of the receipients are going to IBR immediately
  1010. marc Ge0rG, yes, probably but it bugs me that the user won't this
  1011. Ge0rG marc: so let's say I try to generate 100 PARS+IBR tokens. Should I be throttled after 50? Or only after 50 of the tokens have been used?
  1012. marc ups... won't know this
  1013. Ge0rG What if I don't understand how "Send invitation" works and my first 50 tokens get lost?
  1014. marc That's a good question
  1015. Ge0rG marc: I think the only sensible solution is to limit registrations, not token issuance
  1016. Ge0rG marc: so your 51st friend will get a "this token is invalid" response to IBR
  1017. marc Ge0rG, wow, but that's strange isn't it?
  1018. Ge0rG marc: is it?
  1019. marc You generate a valid token and somehow it doesn't work although the token isn't expired
  1020. Ge0rG marc: do you have unlimited IBR on your server?
  1021. marc Ge0rG, I have no IBR at all
  1022. Ge0rG marc: my server will block out after three registrations from the same IP
  1023. arc has joined
  1024. marc Ge0rG, I would limit the token generation either based on time or amount or both...
  1025. marc Every token has an expiration date..
  1026. Ge0rG marc: yes, but that's independent of your potential abuse scenario
  1027. marc Ge0rG, why? A user is not allowed to invite more than X people, for example?
  1028. Ge0rG marc: your ad-hoc command could also return a text field that explains the token validity
  1029. Ge0rG marc: if a user is allowed to invite X people, and he generated X invitations already that all were lost. What then?
  1030. Ge0rG marc: another ad-hoc command to reset pending invitations?
  1031. marc Ge0rG, well, this depends on server operations anyway. But you could allow token generation after all tokens were expired?
  1032. Ge0rG marc: so the user is blocked for two weeks?
  1033. Alex has left
  1034. marc Ge0rG, depends on your lifetime?
  1035. Ge0rG marc: yes. Maybe it's two days. But how is that useful?
  1036. marc Ge0rG, maybe not more then X tokens in a hour?
  1037. Ge0rG marc: maybe, but I still think that you should limit account registrations instead.
  1038. Ge0rG marc: and even if you don't, you can easily link all the new accounts to the initial abuser.
  1039. Ge0rG marc: think about it some more, I'm out for tonight.
  1040. marc Ge0rG, I don't know. If a token doesn't work and is valid with respect to the expiration date it is confusing and wrong IMO
  1041. Ge0rG P.S: protocol design is hard.
  1042. marc No, good protocol design it hard ;)
  1043. lumi has joined
  1044. la|r|ma has left
  1045. Guus has left
  1046. moparisthebest ‎[04:11:00 PM] ‎marc‎: Ge0rG, depends on your lifetime? ‎[04:11:16 PM] ‎Ge0rG‎: marc: yes. Maybe it's two days.
  1047. moparisthebest wow context matters
  1048. efrit has joined
  1049. arc has left
  1050. arc has joined
  1051. sonny has left
  1052. Alex has joined
  1053. goffi has joined
  1054. daniel has left
  1055. jcbrand has left
  1056. efrit has left
  1057. jere has joined
  1058. Tobias has joined
  1059. arc has left
  1060. arc has joined
  1061. arc has left
  1062. ralphm has joined
  1063. arc has joined
  1064. jere has joined
  1065. jere has joined
  1066. jubalh has joined
  1067. matlag has left
  1068. marc has left
  1069. moparisthebest has left
  1070. arc has left
  1071. arc has joined
  1072. arc has left
  1073. blabla has left
  1074. Bunneh has left
  1075. arc has joined
  1076. jubalh has left
  1077. Bunneh has joined
  1078. intosi has joined
  1079. Bunneh has left
  1080. Bunneh has joined
  1081. Steve Kille has left
  1082. lumi has joined
  1083. jere has joined
  1084. moparisthebest has joined
  1085. marc has left
  1086. jubalh has joined
  1087. zinid has joined
  1088. edhelas is there a proper way today to know if a remote MUC has been disconnected ? (like the service went down…)
  1089. intosi has left
  1090. intosi has joined
  1091. zinid edhelas: ping your nick
  1092. Steve Kille has joined
  1093. lumi has joined
  1094. zinid has left
  1095. mimi89999 has joined
  1096. Ge0rG And pray that none of your clients disconnects or lags in that time
  1097. tux has left
  1098. lskdjf has left
  1099. lskdjf has joined
  1100. Alex has left
  1101. lskdjf has left
  1102. lskdjf has joined
  1103. lskdjf has left
  1104. lskdjf has joined
  1105. lskdjf has left
  1106. lskdjf has joined
  1107. lskdjf has left
  1108. lskdjf has joined
  1109. lskdjf has left
  1110. lskdjf has joined
  1111. lskdjf has left
  1112. lskdjf has joined
  1113. daniel has left
  1114. daniel has joined
  1115. daniel has left
  1116. intosi has left
  1117. daniel has joined
  1118. intosi has joined
  1119. intosi has left
  1120. lskdjf has left
  1121. lskdjf has joined
  1122. lskdjf has left
  1123. lskdjf has joined
  1124. arc has left
  1125. arc has joined
  1126. lskdjf has left
  1127. lskdjf has joined
  1128. arc has left
  1129. lskdjf has left
  1130. lskdjf has joined
  1131. arc has joined
  1132. lskdjf has left
  1133. lskdjf has joined
  1134. edhelas has left
  1135. edhelas has joined
  1136. Holger has left
  1137. daniel has left
  1138. daniel has joined
  1139. Holger has left
  1140. lskdjf has left
  1141. lskdjf has joined
  1142. Holger has left
  1143. lumi has joined
  1144. daniel has left