XSF Discussion - 2017-12-05

  1. jjrh has left
  2. lumi has left
  3. jjrh has left
  4. Guus has left
  5. Kev has left
  6. sonny has joined
  7. jubalh has joined
  8. Guus has left
  9. jjrh has left
  10. arc has left
  11. arc has joined
  12. arc has left
  13. arc has joined
  14. matlag has joined
  15. goffi has left
  16. jjrh has left
  17. jjrh has left
  18. la|r|ma has left
  19. sonny has left
  20. sonny has joined
  21. la|r|ma has left
  22. Tobias has joined
  23. lskdjf has left
  24. Tobias has left
  25. lskdjf has joined
  26. goffi has joined
  27. lskdjf has left
  28. lskdjf has joined
  29. sonny has left
  30. la|r|ma has left
  31. sonny has joined
  32. goffi has left
  33. lskdjf has joined
  34. efrit has joined
  35. efrit has left
  36. jere has left
  37. jere has joined
  38. jere has left
  39. jere has joined
  40. Tobias has joined
  41. Tobias has joined
  42. jere has left
  43. sonny has joined
  44. jere has joined
  45. uc has joined
  46. Tobias has joined
  47. matlag has joined
  48. @Alacer has joined
  49. la|r|ma has joined
  50. la|r|ma has joined
  51. Lance has joined
  52. Lance has left
  53. uc has joined
  54. mimi89999 has left
  55. mimi89999 has joined
  56. mimi89999 has joined
  57. uc has joined
  58. zinid has joined
  59. blabla has left
  60. jere has joined
  61. marc has joined
  62. alacer has joined
  63. alacer has left
  64. alacer has joined
  65. alacer has left
  66. sonny has joined
  67. zinid has left
  68. Tobias has left
  69. Tobias has joined
  70. ralphm has left
  71. zinid has joined
  72. ralphm has left
  73. ralphm has joined
  74. ralphm has left
  75. Guus has left
  76. Tobias has joined
  77. Tobias has joined
  78. Guus has left
  79. waqas has left
  80. Guus has left
  81. zinid has left
  82. lskdjf has joined
  83. sonny has left
  84. sonny has joined
  85. intosi has joined
  86. Kev has joined
  87. marc Ge0rG, Did you take a look at the XEP?
  88. sonny has left
  89. sonny has left
  90. Zash has left
  91. arc has left
  92. arc has joined
  93. lskdjf has joined
  94. sonny has joined
  95. Zash has joined
  96. sonny has joined
  97. sonny has left
  98. sonny has joined
  99. marc has left
  100. stefandxm has left
  101. Ge0rG marc: you mean at the examples? 😜 yes, I did
  102. marc Ge0rG, yes the examples ;) Any objections so far? :P
  103. arc has left
  104. arc has joined
  105. daniel has left
  106. daniel has joined
  107. Martin has joined
  108. Ge0rG marc: I still think that the ad-hoc command has two parameters too many. Also not sure about just adding another element to the IBR request
  109. stefandxm has joined
  110. goffi has joined
  111. marc Ge0rG, these two elements are still optional ;)
  112. marc Ge0rG, do you have an other idea for IBR?
  113. Ge0rG marc: I'm not sure means I don't know if this can be made legal by the XEP. The alternative would be to use full fledged Data Forms
  114. stefandxm has left
  115. Ge0rG marc: and it needs some way to integrate with PARS, so that users who already have an account will be accounted for as well
  116. marc Ge0rG, what do you mean? can you give me an exmaple?
  117. arc has left
  118. arc has joined
  119. daniel has left
  120. daniel has left
  121. intosi Yay. Spim from @yax.im.
  122. ralphm has joined
  123. goffi Hi, https://news.ycombinator.com/item?id=15850597
  124. goffi some votes may help ;)
  125. Tobias intosi, also got it and put the domain on my blocklist. but maybe Ge0rG can get his act together and prevent these things
  126. SouL Of course! yes goffi :D
  127. edhelas upvoted :p
  128. Zash Ge0rG: How's your acting?
  129. Flow jonasw, no ProtoXEP annoucement for ISR 0.0.5? I also don't see a council trello card for it
  130. Flow goffi, upvoted, also read the blog post, sounds great!
  131. zinid has left
  132. Steve Kille has left
  133. Steve Kille has left
  134. Tobias goffi, why does the vidoe have white bars top and bottom?
  135. goffi Tobias: because it's old blog renderer and the CSS is bad
  136. jonasw Flow, no
  137. jonasw I don’t do that normally, I thought your mail was announcement enough
  138. jonasw maybe CC council@ next time
  139. goffi but can't use the new one yet (which is responsive), there is not yet atom feed or pagination.
  140. edhelas you shouldn't enforce width and height for the video size
  141. jonasw (ProtoXEP updates are out-of-process, so there’s no tooling for this)
  142. Flow jonasw, ok, i've a feeling that people will refuse to deal with the submission if it's not officially announced. Would you be so kind and add a card to council's trello?
  143. jonasw I doubt that people will refuse that
  144. jonasw I am in a meeting right now
  145. Flow hope so
  146. jonasw remind me in a few hours, then I’ll do that
  147. Ge0rG Tobias: seriously? You've blocked yax.im?
  148. Tobias Ge0rG, if domains send spam my way, i block them :)
  149. Steve Kille has joined
  150. nyco has left
  151. nyco has joined
  152. jonasw Tobias, maybe first contact the admin?
  153. jonasw that’s kinda extreme
  154. Tobias it's even the less harsh approach, compared to others who whitelist domains they do s2s with :)
  155. jonasw especially if the admin is part of the XMPP core-ish community
  156. Tobias jonasw, well...i can unblock them
  157. Tobias even did so after a week
  158. zinid has left
  159. Ge0rG Tobias: that makes me very sad, still
  160. Tobias it also makes me very sad that i received spam from your domain
  161. zinid has joined
  162. Ge0rG Tobias: so what would be your proposed solution? Shut down all public servers?
  163. ralphm has joined
  164. Tobias no...apply some limitations to new accounts on public servers
  165. Guus Oh, I'm with Tobias: I've blocked various domains that delivered nothing to mine, except spam.
  166. daniel has left
  167. Tobias and monitor behaviour of new accounts on public servers
  168. Tobias i have more than 50 domains on my block list
  169. Guus oh, i ~10 :)
  170. Ge0rG Tobias: I'm doing the following: - limit IBR per IP - monitor large numbers of outgoing messages and block accounts - limit the number of stanzas a client can send - watch my logs - react to abuse reports as fast as I can
  171. Ge0rG Tobias: and you didn't even report it to me.
  172. Tobias Ge0rG, will do the next time, I promise
  173. Ge0rG Tobias: you still can report the message content that you received :P
  174. SouL says: come on, cheer up everybody yay :)
  175. Ge0rG Tobias: I know how annoying spam is, and it really really really makes me sad to learn about it in such a public-shaming way.
  176. edhelas Tobias Guus is it possible to get thoses blacklists ?
  177. daniel has left
  178. Tobias edhelas, yes
  179. Ge0rG Tobias: so what's the spam message you received, anyway? I'd like to improve my outbound filters.
  180. Tobias Ge0rG, just going through my logs to find it
  181. Ge0rG Tobias: and did you receive it from digital.advert307@yax.im or a different JID?
  182. Guus edhelas, I can look them up for you. Note that because _my_ users aren't appear to be talking to valid accounts on those domains, yours might. I'm not sure if a permanent blacklisting is approriate.
  183. daniel has left
  184. Zash I also block on first offence. I am evil.
  185. Ge0rG Tobias: so I've just deleted eight spammer accounts that connected through the same IP address. If you had told me the JID or the content of the message you received (did you receive one at all?), I possibly could have deleted more.
  186. Tobias Ge0rG, does your server ping every s2s connection every minute? even if you don't send other messages over that connection for a longer time?
  187. Ge0rG Tobias: it does ping other servers, but I'm not sure if it is actually set to one minute. Why?
  188. Zash wc -l blocklist/zash.dat 256 blocklist/zash.dat
  189. Zash Eeeeeeeevil
  190. Tobias just looking at my log
  191. Ge0rG Zash: how often will prosody 0.10 send whitespace via s2a?
  192. Ge0rG Zash: how often will prosody 0.10 send whitespace via s2s?
  193. Zash Ge0rG: We never got around to adjusting the timeout, so after 6h of silence.
  194. Ge0rG mod_pinger should only ping c2s, from reading the source code.
  195. jonasw dwd, I added ProtoXEP ISR to the proposed agendums [sic]
  196. jonasw (cc @ Flow)
  197. sonny has left
  198. daniel has left
  199. Ge0rG Zash: why is it sending two whitespaces per minute on an s2sin then? And also one ping per minute on s2sout?
  200. sonny has left
  201. Zash Ge0rG: Are you using 3rd party plugins that I have no idea about what they are doing?
  202. Ge0rG Zash: if by "3rd party" you mean "from prosody-modules", then yes.
  203. Zash Yes, I do
  204. Ge0rG Zash: where is the code that sends the once-in-6hr whitespace?
  205. Zash Ge0rG: In mod_s2s, when the network backend invokes the "read timeout" handler.
  206. Zash Have you perhaps changed the read timeout setting?
  207. Ge0rG Zash: I have. `network_settings.read_timeout = 840` - which is NOT 60 seconds.
  208. Ge0rG Zash: also why should it send twice on an s2sin link?
  209. Zash Ge0rG: Duno. Bug?
  210. Ge0rG just to pick a random s2s: Dec 05 10:18:52 s2sin98ca6d0 debug sending: Dec 05 10:18:52 s2sin98ca6d0 debug sending: Dec 05 10:18:52 s2sin98ca6d0 debug Received[s2sin]: <iq id='keepalive' type='result' to='yax.im' from='tengu.chat'> Dec 05 10:19:52 s2sin98ca6d0 debug sending: Dec 05 10:19:52 s2sin98ca6d0 debug sending: Dec 05 10:19:52 s2sin98ca6d0 debug Received[s2sin]: <iq id='keepalive' type='result' to='yax.im' from='tengu.chat'>
  211. Zash Ge0rG: Weird. Libevent?
  212. daniel has left
  213. Ge0rG Tobias: thanks for pointing out the bug. Were you able to find anything in your logs regarding that spammer you encountered?
  214. Tobias not yet...will tell you in about half an hour
  215. daniel has left
  216. jonasw zinid, if you’re doing strict schema validation, how do you handle the lax order requirements of XMPP?
  217. jonasw which cannot really be reflected in schemas?
  218. jonasw (well, somebody did the work to reflect that in XEP-0030, but ...)
  219. Bunneh has left
  220. Bunneh has joined
  221. Ge0rG Sigh. Blocking messages from strangers is really annoying. I get a subscription request from a JID I don't recognize and I can't even ask them why they contact me without exposing my presence.
  222. daniel has left
  223. daniel has left
  224. Ge0rG Oh, `admin@xmpp.wiki` is not actually an admin.
  225. daniel has left
  226. SouL Does .wiki domain exist?
  227. Zash Looks like one of chatmes domains?
  228. SouL Didn't know that
  229. Ge0rG Zash: yes, it is.
  230. stefandxm has joined
  231. mathieui mod_block_registrations should also be required for IBR servers…
  232. mathieui with admin, operator, and root banned
  233. Ge0rG mathieui: right, that too.
  234. Ge0rG block_registrations_users = { "abuse", "admin", "administrator", "hostmaster", "info", "news", "noc", "owner", "postmaster", "register", "registration", "root", "security", "service", "signup", "support", "sysadmin", "sysop", "system", "test", "trouble", "webmaster", "www", "xmpp", }
  235. Ge0rG based on http://tools.ietf.org/html/rfc2142 and http://blog.postbit.com/reserved-username-list.html
  236. Ge0rG added `operator` now.
  237. Ge0rG Zash: ^
  238. Zash Ew, spaces for indentation!
  239. Ge0rG Zash: what? I'm using tabs.
  240. Zash The module
  241. SouL wtf who uses tabs for indentation
  242. ralphm This
  243. Zash No, TABS! Holy war!
  244. mathieui oh no
  245. mathieui maybe we should talk about tea instead
  246. Zash No, Coffee! Holy war!
  247. mathieui nobody expects the xmpp inquisition
  248. sonny has left
  249. Ge0rG mathieui: nobody expects the whitespace inquisition?
  250. Tobias Ge0rG, https://q.zash.se/a6db0f2a6dcf.txt
  251. Ge0rG Tobias: that's been almost two weeks ago!?
  252. Tobias yes?
  253. Ge0rG Tobias: you didn't know that I'm the admin of yax.im?
  254. Tobias i did
  255. Tobias like I said, next time I'll report it to you before blocking your domain
  256. Ge0rG Tobias: sorry, but I'm speechless.
  257. Tobias is the account already deleted?
  258. Ge0rG BTW, there is a dozen of accounts that used the same IP address.
  259. Ge0rG Tobias: no. I'm not even sure why the message went out at all. It should be blocked for multiple reasons.
  260. Tobias like high percentage of YELLING?
  261. Ge0rG Tobias: I'm not measuring that. But multi-line messages to non-subscribers should be blocked.
  262. Holger jonasw: What order requirement can't be reflected?
  263. sonny has left
  264. Zash Ge0rG: does `prosodyctl mod_firewall test` work?
  265. Holger jonasw: Either way ejabberd is using it's own schema format, not XSD.
  266. daniel has left
  267. Ge0rG Zash: I remember now. my `bodycheck` rule had to be disabled for outgoing messages because IN_ROSTER doesn't work in `::preroute`
  268. Zash Say what
  269. sonny has joined
  270. zinid jonasw, we don't use XSD, they are shit
  271. Ge0rG Zash: what does IN_ROSTER return when applied in the ::preroute chain?
  272. Zash Ge0rG: Oh right, because it refers to the receivers roster, which wouldn't be available for a remote user
  273. Ge0rG Zash: so how do I find out if the local sender is subscribed to the remote receiver?
  274. zinid jonasw, it has erlangish format, here it is: https://github.com/processone/xmpp/blob/master/specs/xmpp_codec.spec
  275. Zash Ge0rG: And the sender can just add whatever they want to their roster, so you'd need the thing, yes, subscription check
  276. Ge0rG SUBSCRIBED Tests whether the recipient is subscribed to the sender, ie will receive presence updates from them. Note that this does work, regardless of direction and which chain is used, since both the sender and the recipient will have mirrored roster entries.
  277. Zash Ge0rG: SUBSCRIBED?
  278. Zash Right
  279. Ge0rG is that what I need? Will it work as expected?
  280. Zash Ge0rG: Unless it has the same bug...
  281. Ge0rG Zash: actually I need the opposite - whether the sender is subscribed to the receiver.
  282. Zash Ge0rG: Why?
  283. Ge0rG Whoever invented asymmetric presence subscription.
  284. Ge0rG Zash: because a spammer could pre-approve all receivers?
  285. Zash Ge0rG: But that's not implemented! :D
  286. Ge0rG Zash: ah, it looks like `rostermanager.is_contact_subscribed` will actually check both directions.
  287. Alex has joined
  288. daniel has left
  289. Ge0rG Zash: thanks very much.
  290. Ge0rG So now I can apply a `JUMP_CHAIN=user/bodycheck` to outgoing messages as well. But how can I add another action to inform the admin about local users spamming?
  291. Ge0rG JUMP_CHAIN will BOUNCE when spam was found.
  292. Alex has left
  293. Ge0rG Tobias: deleted the twelve spammer accounts. Improved firewall rules. Sent abuse report to ISP. Thanks for reporting.
  294. Tobias ta
  295. daniel has left
  296. daniel has left
  297. jonasw Holger, in XMPP, the order of elements of different names (e.g. <{disco}feature/> and <{disco}identity/>) is irrelevant. this can be, but is very hard to, represent with XSD
  298. jonasw but sure, if you use your own validation, that doesn’t affect you, zinid
  299. zinid this is not strictly speaking the validation, it's more like ASN.1 codec, which transforms XML into internal language structure
  300. zinid but validation is performed during decoding, yes
  301. jonasw you have a weird obsession for ASN.1
  302. jonasw which is fine, I guess
  303. moparisthebest has joined
  304. tux zinid: You do Erlang, too? xD
  305. moparisthebest has joined
  306. tux (just kidding)
  307. jcbrand has joined
  308. zinid tux, well, erlang knowledge is required for ejabberd development, most of the time 🙂
  309. daniel has left
  310. Holger jonasw: <xs:complexType><xs:all><xs:element name="feature"/><xs:element name="identity"/></xs:all></xs:complexType> won't do the trick?
  311. zinid jonasw, ha, you didn't see my obsession regarding parsers yet 😀
  312. jonasw Holger, afaik not
  313. jonasw I.
  314. zinid jonasw, for example, from this ABNF file https://github.com/processone/xmpp/blob/master/c_src/uri.abnf the parser code is generated: https://github.com/processone/xmpp/blob/master/c_src/xmpp_uri.c
  315. jonasw I think that enforces order between feature and identity
  316. jubalh has joined
  317. Holger jonasw: No. That would be xs:sequence instead of xs:all.
  318. jonasw Holger, tbh, I have not much of an idea about XSD, I tried to read the spec and I find it massively confusing
  319. jonasw there have been some comments w.r.t. on standards@
  320. Ge0rG Ah, the new rules absolutely pay off. Found another 18 spammer accounts.
  321. tux zinid: yeah, that's true. 8)
  322. Holger jonasw: I'm not much into it either, dunno whether you can express all XMPP syntax weirdness with XSD.
  323. sonny has left
  324. intosi has left
  325. sonny has joined
  326. daniel has left
  327. Steve Kille has left
  328. sonny has left
  329. daniel has left
  330. mhterres has joined
  331. mhterres has left
  332. Ge0rG inetnum: - netname: FVDE descr: Tor Exit Node Hosting
  333. Ge0rG Whoops. Four of five IPs that injected spam today are exit nodes.
  334. zinid wow, suddenly
  335. lumi has joined
  336. daniel has left
  337. zinid just ban all exit nodes 😀
  338. Zash Require all Tor users fill in a Google Captcha!
  339. daniel has left
  340. intosi has joined
  341. @Alacer has left
  342. @Alacer has joined
  343. lskdjf has joined
  344. intosi Ge0rG: good busy!
  345. daniel has left
  346. Ge0rG Okay, so I've deleted another 50 accounts
  347. stefandxm has left
  348. daniel has left
  349. Steve Kille has left
  350. stefandxm has joined
  351. jere has joined
  352. Syndace has left
  353. Syndace has joined
  354. la|r|ma has joined
  355. moparisthebest has joined
  356. moparisthebest has joined
  357. la|r|ma has left
  358. la|r|ma has joined
  359. blabla has joined
  360. Alex has joined
  361. daniel has left
  362. jubalh has left
  363. Ge0rG @iteam - our wiki claims "The XMPP Standards Foundation maintains a dedicated email list (muc@xmpp.org) about MUC" but there is no such list. Does anybody want one?
  364. jonasw I’m pretty sure I was on that list.
  365. jonasw it was deleted though
  366. lskdjf has joined
  367. jonasw Subject: [MUC] deleting this list Date: 14.02.13 05:09 From: Peter Saint-Andre <stpeter@stpeter.im> To: muc@xmpp.org I just deleted the specialized bosh@xmpp.org list. I think it would be appropriate to do the same with the muc@xmpp.org list. Instead of having a specialized conversation here, we'll simply use the main standards@xmpp.org list. Any objections? Peter
  368. jonasw the only reply to that was from someone who claimed to not have done anything with jabber for 3 years
  369. Ge0rG How appropriate.
  370. daniel has left
  371. Zash Hah
  372. jonasw TBH, I don’t see a use-case for separate lists
  373. jonasw Ge0rG, edit that out of the wiki maybe?
  374. Zash jonasw: Very active topics that drown out others?
  375. Ge0rG jonasw: done
  376. jonasw Zash, I find standards@ still comfortable to read
  377. Kev I think it's more about interests not overlapping than about traffic.
  378. Ge0rG If only we had threaded email-like message support in XMPP.
  379. Zash It works like a sort of filter, but enforced by the sender instead of the receiver
  380. Kev If you expect the same people on both lists, it's not gaining much, but if you think lots of people care about MUC, but not other stuff on standards@ there's a point.
  381. Kev I don't think there is in this case.
  382. la|r|ma has joined
  383. daniel has left
  384. marc has left
  385. jcbrand has left
  386. uc has joined
  387. ralphm has joined
  388. uc has joined
  389. Alex has left
  390. lskdjf has left
  391. daniel has left
  392. daniel has joined
  393. jubalh has joined
  394. sonny has joined
  395. Holger has left
  396. Martin has left
  397. zinid has left
  398. marc has left
  399. efrit has joined
  400. lovetox has joined
  401. Alex has joined
  402. Ge0rG has left
  403. jonasw Ge0rG, why aren’t you in jdev@?
  404. Ge0rG jonasw: I'm not?
  405. jonasw now you’re
  406. Ge0rG jonasw: I had a power outage.
  407. waqas has joined
  408. waqas has left
  409. tux has joined
  410. tux has joined
  411. jere has joined
  412. jere has joined
  413. jjrh has left
  414. jjrh has left
  415. efrit has left
  416. jjrh has left
  417. daniel has left
  418. marc has joined
  419. jjrh has left
  420. jcbrand has joined
  421. blabla has left
  422. daniel has left
  423. Tobias has left
  424. Zash has left
  425. daniel has left
  426. jubalh has left
  427. jubalh has left
  428. jubalh has joined
  429. sonny has left
  430. jonasw zinid, re your standards@ reply: > Well, yes, it will be timed out. I also don't think this is a > violation, because in this case we cannot block IQ from flooders for > example, as this is also a violation.
  431. jonasw I would suggest to send some IQ type="error" back in these cases
  432. jonasw and making IQ requests timeout is super-annoying
  433. Kev You can't type=error to a result or an error.
  434. jonasw Kev, yes
  435. jonasw this was in response to what he said about flooders
  436. jonasw (which is why I didn’t reply on the standards@ thread)
  437. stefandxm has left
  438. sonny has left
  439. sonny has left
  440. sonny has left
  441. marc has left
  442. marc has joined
  443. zinid jonasw, why would I send iq=errors to flood IQs? wtf?
  444. zinid what if this is a dos attack, I should do that too?
  445. jonasw zinid, depends on how sure you are that it’s a genuine flood
  446. zinid ok, so if I want that much, then I can 🙂
  447. jonasw if might also be a client which is confused or simply has a lot of things to do. sending proper type="wait" errors back.
  448. jonasw it might also be a client which is confused or simply has a lot of things to do. sending proper type="wait" errors back.
  449. jonasw it might also be a client which is confused or simply has a lot of things to do. sending proper type="wait" errors back seems more reasonable to me, until it becomes a burden.
  450. zinid whatever, as daniel said any discussions are pointless
  451. zinid you already built up your mind, why bother
  452. zinid I'm also not sure why on earth I should route (or store) malformed packets
  453. daniel has left
  454. jonasw because you can’t be sure that they’re malformed
  455. zinid jonasw, I can if I have schema
  456. jonasw okay, but then you have to consider how schemas are used in XMPP and acknowledge that elements and attributes may be added at any time, and must be ignored
  457. zinid well, that's the rule I don't like
  458. jonasw I know that
  459. jonasw but that’s how XMPP works and has always worked
  460. jonasw (*always: to my knowledge)
  461. zinid and where is it now?
  462. jonasw I don’t think that this specific rule is the cause of the low popularity of XMPP
  463. daniel has left
  464. zinid it can be pretty much though
  465. jonasw how?
  466. zinid what? lack of formal validation of packets/
  467. zinid ?
  468. zinid for example, some people would rather use something more robust, like asn.1
  469. jonasw you can formally validate what you know about, there’s no problem with that
  470. jonasw no, if you’re going down the "no XML" route, what people nowadays want to use is JSON
  471. zinid but I know there is no <retry/> element in the schema
  472. jonasw in which schema?
  473. jonasw the one you made up, or the non-normative which may or may not be in the XEP?
  474. zinid ah, indeed, we don't even have schemas
  475. jonasw exactly
  476. Zash The 'critical' property of things in ASN.1 sure seems nice
  477. jonasw because the rule I mentioned earlier (unknown things need to be ignored, and also the order of things does not matter) is hard to codify in XMLSchema
  478. jonasw Zash, google dropped "required" in protocol buffers 3.0
  479. jonasw (critical is "you have to understand it", right?)
  480. zinid jonasw, yeah, and you resorted for postulate this ad-hoc
  481. jonasw zinid, I don’t understand your statement, sorry, could you rephrase?
  482. Zash jonasw: Yes. If you don't understand something marked 'critical' then that's a fatal error and you should abort everything.
  483. Zash Much nicer than just blanked ignoring of everything not understood.
  484. jonasw Zash, idneed
  485. jonasw we could have that, if we wanted to
  486. Zash In XML? Hrrrm
  487. jonasw but even then I’d find it questionable for a server to decide what a client understands
  488. jonasw Zash, xmpp:critical="true", define xmpp prefix on <stream:stream/>, be done with it :-)
  489. jonasw but SamWhited will kill me for that
  490. Zash It probably wouldn't have much use outside of initial stream negotation
  491. jonasw possibly
  492. Zash Well. Depends
  493. Zash Altho that's working fine enough.
  494. Kev has left
  495. zinid jonasw, nah, I'm pretty much bored
  496. zinid jonasw, I will anyway do what I think better
  497. daniel has left
  498. sonny has left
  499. Guus has left
  500. sonny has left
  501. sonny has joined
  502. sonny has joined
  503. ralphm has left
  504. ralphm has left
  505. sonny has left
  506. jubalh has left
  507. sonny has left
  508. jere has joined
  509. sonny has left
  510. Tobias has joined
  511. Lance has joined
  512. Lance has left
  513. daniel has left
  514. @Alacer has left
  515. @Alacer has joined
  516. Guus has left
  517. Tobias has left
  518. Tobias has joined
  519. stefandxm has joined
  520. jere has joined
  521. Guus has left
  522. zinid has left
  523. Holger Basic XEP-0060 question. I don't get how the interaction of proper PubSub (non-PEP) nodes with presence is supposed to work.
  524. Holger E.g. pubsub#access_model=presence. This assumes the PubSub service has access to the node owner's roster data? The node owner might be a remote user, no?
  525. jonasw yes, I think so
  526. jonasw that access model probably simply doesn’t work for services where this isn’t true
  527. Holger Or pubsub#send_last_published_item=on_sub_and_presence (this is even the default).
  528. ralphm has joined
  529. Holger This assumes the PubSub service will receive presence from the subscriber?
  530. jonasw probably
  531. Holger It's like these parts of 0060 were written without federation in mind.
  532. stefandxm has left
  533. jubalh has joined
  534. Zash In theory, the service could send a presence request
  535. jonasw Zash, so it’d have to regularly type="probe" the subscribers?
  536. arc has left
  537. Zash jonasw: if it's subscribed, it should get presence pushed to it, like any other contact
  538. ralphm has joined
  539. arc has joined
  540. jubalh has left
  541. ralphm has joined
  542. jonasw oh good point
  543. ralphm has left
  544. ralphm has joined
  545. Syndace has left
  546. Syndace has joined
  547. Guus has left
  548. zinid you still need to send probes after restart
  549. la|r|ma has left
  550. Zash Sure, it would have to do the things the server does for users with rosters.
  551. Guus has left
  552. zinid has left
  553. nyco has left
  554. nyco has joined
  555. ralphm has joined
  556. jere has joined
  557. jubalh has joined
  558. SamWhited has joined
  559. Steve Kille has left
  560. Steve Kille has left
  561. ralphm has joined
  562. Steve Kille has joined
  563. ralphm has joined
  564. stefandxm has joined
  565. jonasw Zash, do servers do that on behalf of components?
  566. jonasw argh
  567. jonasw nevermind, I misread your sentence
  568. Steve Kille has left
  569. stefandxm has left
  570. zinid has left
  571. Ge0rG has left
  572. ralphm has joined
  573. sonny has left
  574. sonny has left
  575. sonny has left
  576. daniel has left
  577. ralphm has left
  578. ralphm has joined
  579. jcbrand has left
  580. zinid has left
  581. ralphm has left
  582. ralphm has joined
  583. tux has joined
  584. daniel has left
  585. Tobias has left
  586. Tobias has joined
  587. bear has left
  588. bear has joined
  589. sonny has joined
  590. ralphm has left
  591. Ge0rG has left
  592. sonny has joined
  593. daniel has left
  594. stefandxm has joined
  595. Guus has left
  596. daniel Briefly looking over Ge0rG's email. Retraction... Wait there is a retraction feature in MIX? 😂
  597. daniel That makes me wonder what else is in there
  598. jonasw that mail is long enough to make kmail think for a moment before showing it. well done, Ge0rG
  599. Ge0rG daniel: that mail was shorter than I expected.
  600. jonasw that mail is long enough to make kmail think for a moment before showing it. well done, Ge0rG)
  601. daniel I wonder if Georg will be talking about the dish washing feature later in the email
  602. jonasw :D
  603. Ge0rG no, but there is a valet parking feature.
  604. daniel For scooter and cars?
  605. Steve Kille daniel: there is both user and administrator retraction. Both can be configured on or off
  606. Ge0rG for gas driven locomotives
  607. Steve Kille Ge0rG: will add the valet parking feature in next update
  608. Steve Kille Ge0rG: I plan to respond to your email later this week
  609. Ge0rG Steve Kille: I think there is no need to hurry. It took me multiple weeks to read the XEP and write the mail, so take your time :)
  610. lovetox has left
  611. daniel Ge0rG, LMC should probably be changed to use origin-ids
  612. intosi Steve Kille: is this valet parking feature available for my office trip next week? :)
  613. Guus has left
  614. Ge0rG daniel: I think the stanza-id XEP should be changed to enforce a client setting message-id = origin-id.
  615. Ge0rG intosi: only if you implement MIX 2.0 until then
  616. ralphm has joined
  617. daniel Ge0rG, probably. but that's orthogonal to changing LMC et al to using origin-ids
  618. Ge0rG daniel: changing LMC et all would be a breaking change.
  619. daniel and most sane implementations will already set message-id=origin-id
  620. daniel Ge0rG, sure
  621. daniel but it's a breaking change either way
  622. Ge0rG daniel: it's not a breaking change to fix stanza-id ;)
  623. daniel yes?! but it's still orthogonal
  624. Ge0rG daniel: you might resurrect the thread I had with Flow regarding that topic in October.
  625. Ge0rG let's say its complementary.
  626. stefandxm has left
  627. daniel even if you force origin-id to be the same as message-id. if lmc gives origin-id precedence over message-id that's still a breaking change
  628. daniel because that xep has to deal with the case where they are not the same
  629. Ge0rG can't we just properly fix message-id, once and for all?
  630. daniel fix meaning?
  631. Ge0rG mandate globally unique message IDs
  632. Ge0rG and just plain reject messages that violate that rule
  633. daniel that doesn't prevent services from rewriting the id though
  634. daniel which is imho the bigger issue
  635. Ge0rG daniel: stopping id rewriting would be the other part of fixing message-id
  636. Zash But is the outgoing message from a MUC really the same message as the incoming one?
  637. daniel has left
  638. Ge0rG Zash: if a tree falls in a MUC, and there are no participants, will there be a presence update?
  639. Zash Schrödingers presence update.
  640. Alex has left
  641. Ge0rG Zash: when you want to LMC a MUC message you just sent, will you use the sent-message-id, the reflected-message-id, the MAM id or the origin-id?
  642. daniel origin-id
  643. daniel (once the XEP says so)
  644. Ge0rG Zash: is it the MUC service's task to track all message ID references it rewrites and fix them?
  645. zinid origin-id, stanza-id
  646. zinid you guys are reinventing version vectors and vector clocks
  647. daniel has left
  648. Ge0rG http://www.abdsphysics.com/uploads/6/5/0/9/65090265/4802565.png?540
  649. Ge0rG I think that it's very typical for the XMPP standardization process that we end up with a message having three different IDs.
  650. daniel has left
  651. Zash Why don't we stick a nonce in each message, apply canonicalization and declare that the message id is a hash of the canonical serialization of it?
  652. daniel fwiw Conversations already gives origin-id precedence over stanza-id when it comes to LMC, reciepts chat markers
  653. Zash /s ;)
  654. Ge0rG daniel: please comment on the "UPDATED: XEP-0359 (Unique and Stable Stanza IDs)" thread.
  655. jjrh has left
  656. jcbrand has joined
  657. Guus has left
  658. Ge0rG daniel: thanks! :)
  659. zinid has left
  660. daniel has left
  661. jjrh has left
  662. Guus has left
  663. jubalh has joined
  664. sonny has left
  665. jubalh has left
  666. sonny has joined
  667. sonny has joined
  668. jubalh has joined
  669. Zash has left
  670. Zash has joined
  671. lumi has left
  672. jcbrand has left
  673. lskdjf has left
  674. Zash has left
  675. stefandxm has joined
  676. jubalh has left
  677. jubalh has joined
  678. jjrh has left
  679. SamWhited has left
  680. ralphm has joined
  681. Guus has left
  682. nyco has left
  683. nyco has joined
  684. moparisthebest has joined
  685. stefandxm has left
  686. Guus has left
  687. tux has joined
  688. jjrh has left
  689. SamWhited has left
  690. SamWhited has joined
  691. daniel has left
  692. Guus has left
  693. marc has left
  694. marc has left
  695. marc has joined
  696. pep. has left
  697. daniel has left
  698. edhelas has left
  699. edhelas has joined
  700. jubalh has left
  701. daniel has left
  702. Kev has joined
  703. Guus has joined
  704. daniel has left
  705. @Alacer has left
  706. marc has left
  707. sonny has joined
  708. @Alacer has joined
  709. daniel has left
  710. sonny has joined
  711. sonny has joined
  712. mimi89999 has joined
  713. goffi has left
  714. Kev has left
  715. lskdjf has left
  716. stefandxm has joined