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