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


  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


  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


  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


  278. Zash


  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


  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


  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


  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


  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


  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


  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


  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


  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


  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


  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


  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