XSF logo XSF Discussion - 2019-08-20


  1. lumi has left
  2. pdurbin has left
  3. Chobbes has joined
  4. aj has joined
  5. adityaborikar has joined
  6. Daniel has left
  7. Daniel has joined
  8. jmpman has left
  9. aj has left
  10. Daniel has left
  11. jmpman has joined
  12. Daniel has joined
  13. Chobbes has left
  14. UsL has left
  15. pdurbin has joined
  16. neshtaxmpp has left
  17. neshtaxmpp has joined
  18. Daniel has left
  19. Daniel has joined
  20. pdurbin has left
  21. Lance has left
  22. curen has joined
  23. Yagiza has joined
  24. UsL has joined
  25. Daniel has left
  26. Daniel has joined
  27. Lance has joined
  28. jmpman has left
  29. waqas has left
  30. Lance has left
  31. Lance has joined
  32. waqas has joined
  33. jmpman has joined
  34. pdurbin has joined
  35. Daniel has left
  36. Daniel has joined
  37. Tobias has joined
  38. pdurbin has left
  39. Lance has left
  40. jmpman has left
  41. curen has left
  42. jmpman has joined
  43. Daniel has left
  44. Daniel has joined
  45. Daniel has left
  46. Lance has joined
  47. waqas has left
  48. aj has joined
  49. ralphm has left
  50. ralphm has joined
  51. wurstsalat has joined
  52. Lance has left
  53. Daniel has joined
  54. jmpman has left
  55. jcbrand has joined
  56. Lance has joined
  57. pdurbin has joined
  58. pdurbin has left
  59. jubalh has joined
  60. remko has joined
  61. Lance has left
  62. Steve Kille has left
  63. Nekit has joined
  64. lskdjf has joined
  65. moparisthebest has left
  66. moparisthebest has joined
  67. Steve Kille has joined
  68. Lance has joined
  69. sezuan has joined
  70. Alex has left
  71. pdurbin has joined
  72. COM8 has joined
  73. pdurbin has left
  74. COM8 has left
  75. COM8 has joined
  76. jmpman has joined
  77. COM8 has left
  78. karoshi has joined
  79. Kev pep.: he's still doing stuff, as he's always been.
  80. ralphm What I mean he doesn't frequent this room, which I thought was what pep. was asking.
  81. pep. yeah
  82. Lance has left
  83. eevvoor has joined
  84. larma has left
  85. eevvoor flow why not XMPP for activists? which alternative is there?
  86. aj has left
  87. eevvoor Of course I would use XMPP if I would like to protect myself.
  88. larma has joined
  89. eevvoor By the why, activists already use(d) mail :D. Snowden did, and DeltaChat popped up for activist usecase. ^^
  90. jonas’ all the metadata
  91. goffi has joined
  92. jmpman has left
  93. Ge0rG It's too hard to use properly if your life depends on it
  94. pep. That's because "we know". I'm sure others "who know" in other protocols would have other concerns about their solutions :x
  95. Lance has joined
  96. ralphm Indeed, other protocols have other issues
  97. Allo has left
  98. Allo has joined
  99. eevvoor until now I cannot see a better protocol than XMPP. Thus I would use it despite my concerns.
  100. eevvoor There exists no perfect solution until now.
  101. eevvoor Anyhow, you can always use your life if your an activist.
  102. eevvoor Anyhow, you can always loose your life if your an activist.
  103. lskdjf has left
  104. eevvoor The enemy comes from all directions. I was always surprised when they appeared.
  105. eevvoor :D
  106. eevvoor has left
  107. lskdjf has joined
  108. Daniel has left
  109. Daniel has joined
  110. Mikaela has joined
  111. ralphm I do think that you'd want full control over your server.
  112. Allo has left
  113. Lance has left
  114. Allo has joined
  115. pdurbin has joined
  116. mr.fister has left
  117. Visitor has joined
  118. Lance has joined
  119. Nekit has left
  120. Visitor has left
  121. Nekit has joined
  122. pdurbin has left
  123. Lance has left
  124. lskdjf has left
  125. lskdjf has joined
  126. adityaborikar has left
  127. adityaborikar has joined
  128. Lance has joined
  129. andrey.g has left
  130. andrey.g has joined
  131. Tobias has left
  132. intosi has left
  133. ralphm has left
  134. Tobias has joined
  135. Lance has left
  136. ralphm has joined
  137. intosi has joined
  138. pdurbin has joined
  139. Lance has joined
  140. LNJ has joined
  141. Alex has joined
  142. Lance has left
  143. Lance has joined
  144. Ge0rG https://mail.jabber.org/pipermail/standards/2017-August/033123.html is a 401?!
  145. pep. Fun
  146. pdurbin has left
  147. ralphm intosi, Kev, MattJ?
  148. Chobbes has joined
  149. Dele (Mobile) has joined
  150. Dele (Mobile) has left
  151. eevvoor has joined
  152. Kev That'll probably be because of the OS upgrade at a guess.
  153. Lance has left
  154. Kev I believe a strict reading of 612[01] would lead to a server rejecting a stanza of <message from='...' to='...'><body un-namespaced-attribute="blah>...</body></message> because of the attribute. I'm currently looking at a patch to M-Link to enforce this. Anyone see issues with enforcing that?
  155. Guus https://opensource.wearespindle.com/ seems interesting
  156. jonas’ Kev, I’m not so sure servers restricting the content of stanzas being routed is a good thing
  157. COM8 has joined
  158. Kev It is what 6120 says though - that no entity should be sending out syntactically invalid stanzas.
  159. flow Kev, a pointer to the relevant parts of the RFCs would be good idea…
  160. ralphm Kev: do you mean unknown namespace prefixes, or unknown attributes without one?
  161. Kev And I suspect you would expect the server to be e.g. bouncing other types of invalid syntax - like message type="nope", for example.
  162. Kev ralphm: Unknown attributes without one.
  163. jonas’ Kev, content vs. headers
  164. ralphm I don't see how that's a syntax violation.
  165. flow well message type="nope" is valid IIRC
  166. jonas’ that, too
  167. flow although I would not recommend it
  168. Zash Huh
  169. Kev flow: no, 6121 enumerates the allowed types.
  170. Kev (And 'nope' isn't one of them
  171. jonas’ Kev, and entities which see an unknown type must (or SHOULD?) treat it as normal
  172. Kev (And 'nope' isn't one of them)
  173. jonas’ Kev, and entities which see an unknown type must (or SHOULD?) treat it as "normal"
  174. Kev jonas’: No, that's not right.
  175. Kev An entity that chooses not to implement support for all the defined types should treat any of the defined types that it doesn't have explicit support for as the default.
  176. Zash Server rejecting `<message><body foo="bar">blah</body></message>` seems totally fine to me.
  177. Kev Not that it should accept ones with an invalid type.
  178. jonas’ Kev, right, I misread that
  179. ralphm type='nope' is *not* invalid for Core?
  180. Kev ralphm: 6120 references 6121 for its rules.
  181. ralphm for IM purposes, yes
  182. flow I always read If an application receives a message with no 'type' attribute or the application does not understand the value of the 'type' attribute provided, it MUST consider the message to be of type "normal" (i.e., "normal" is the default). as "nope" become "normal"
  183. jonas’ flow, above the enumeration, there is "type MUST have one of those values"
  184. Kev flow: You should read the stuff a paragraph or so before as well, which explains it further.
  185. ralphm 6120 without 6121 is a valid use case. Even XEP-0060 doesn't inherently depend on 6121
  186. jonas’ Kev, I’m inclined to say, aside from @to and @from, the server should leave routed stanzas alone.
  187. flow Well it says something about "if included" the type MUST be one of the following ;)
  188. jonas’ flow, yes
  189. jonas’ so it’s either one of the defined ones, or absent. absent defaults to normal.
  190. Kev ralphm: That's a good point, thanks.
  191. ralphm however, 6120 does have a schema with a restricted list of values
  192. flow I think the RFC could be better writen/more clear about that, but I am happy to hear that there appears to be a common ground that "type" sould not carry custom values
  193. jonas’ (non-normative schema?)
  194. jonas’ flow, MUST NOT ;)
  195. Kev jonas’: Incidentally (I'd previously missed this) it's OPTIONAL whether a server does the validation.
  196. ralphm But type on stanza aside, the earlier example is about unknown attributes on the body element. I think that's totally valid. If servers would block that, it might be a problem for forward compatibility.
  197. flow Kev, I still miss the part in the RFC which forbids additional custom unqualified attributes in <body/>
  198. Kev ralphm: What about the other cases, like an iq that has three payloads? I had previously believed that a server should be not allowing those through, but as of about 3 minutes ago I no longer think that.
  199. flow (FWIW, I would be happy if such a part exists)
  200. COM8 has left
  201. Kev flow: "There are no attributes defined for the <body/> element, with the exception of the 'xml:lang' attribute." is the text in question. I think reading that to say that there are no further attributes allowed in the default namespace would be reasonable. But I was sufficiently unsure as to bring it up here :)
  202. ralphm I don't know, think that 8.2.3 ad 5 is pretty convincingly a MUST.
  203. ralphm and to me 'not defined' does definitely not mean 'not allowed'
  204. ralphm Otherwise the whole idea of ignore what you don't know about, goes out the window.
  205. ralphm And rejecting unknown stanza type values is arguably of a different order than unknown attributes.
  206. Kev Well, we've always assumed that 'what you don't know about' will be namespaced.
  207. Lance has joined
  208. Kev But this is all getting a lot muddier than I'd thought it would when I added a ticket for validating syntax.
  209. ralphm Kev: I haven't and there are many specs where new attributes, all not namespaced, were added.
  210. jonas’ which?
  211. ralphm pubsub is one
  212. Kev I couldn't immediately think of any when I was trying earlier, but thought someone else might be able to, thus asking heer.
  213. Kev What does pubsub add?
  214. ralphm I mean new attributes compared to earlier versions of the spec
  215. ralphm e.g. the publisher attribute
  216. Kev Ah. That's somewhat different.
  217. ralphm why?
  218. Kev They're not adding attributes to RFC-defined elements.
  219. ralphm So what if we at some point have a cis and add an attribute to body?
  220. ralphm We'd have a mess of older servers that just won't route?
  221. Daniel has left
  222. Kev I think the argument against blocking the attributes is strong.
  223. ralphm I missed the argument?
  224. Kev You just made one aspect of it :)
  225. Daniel has joined
  226. Kev But we'd also have to not to anything in cis that was illegal in bis, unless we negotiated cis.
  227. Kev Because validation is allowed under bis.
  228. ralphm So where is the part that says you can't have other attributes?
  229. Kev There isn't one. There is one that say they're not defined, and another that says you're allowed to validate.
  230. ralphm The text you quoted doesn't convince me and is not in Core.
  231. Kev So it's a little wooly.
  232. Kev It's not, but it's referenced from core saying "the rules for this are in -im", or somesuch.
  233. Kev I'm sold on not blocking the attributes, though.
  234. ralphm wooly indeed
  235. ralphm I was kinda curious about the threat model, though.
  236. larma has left
  237. larma has joined
  238. Kev So, different question.
  239. Nekit has left
  240. Kev Given than 6120 clearly says that servers are allowed to validate syntax, what /would/ be fair game for validation.
  241. Kev It seems to be saying you're allowed to validate explicitly against the 6120 schema.
  242. ralphm Well, at the very least defined attributes and their values, and indeed things like number of child elements in iq
  243. madhur.garg has left
  244. jcbrand has left
  245. jonas’ Kev, @to, @from (including stringprep!), @type on all stanzas, presence of @id on IQs(?), number of children in IQs, structure of the <error/> child if present
  246. ralphm I think the schema in 6120 is reasonable to check against
  247. jcbrand has joined
  248. Dele (Mobile) has joined
  249. Kev Oh, this gets messy. If I'm reading it right, the schema is more restrictive than the text, but is normative.
  250. madhur.garg has joined
  251. ralphm how is the schema more restrictive?
  252. Kev Ah, no, this is stream errors, not stanza errors, ignore.
  253. jonas’ if the schema is normative: absence of any unspecified jabber:client/jabber:server namespaced children
  254. jonas’ that would show those folks who think they can just drop their XML in there
  255. Kev Ah, interesting, so message types are defined in the 6120 schema. Making them restricted even for non-IM.
  256. ralphm jonas’: I think the schema language had no way to express this
  257. jonas’ ralphm, I’m pretty sure that anything which isn’t allowed explicitly in the schema is forbidden?
  258. Kev Including undefined attributes? :)
  259. ralphm jonas’: why?
  260. Dele (Mobile) has left
  261. jonas’ that’s how XML schema works?
  262. ralphm Kev: on the type values and schema, I mentioned that earlier
  263. Nekit has joined
  264. Kev Sorry Ralph, I can't quite parse what you're saying there. Are you saying you /do/ think that the schema in 6120 restricts undefined attributes on defined elements, and therefore e.g. rejecting ...<body blah='eee'>... is 'ok'?
  265. ralphm No. I think that checking what's in the schema is fair game, but I don't think we should disallow what's not mentioned
  266. ralphm Is that more clear?
  267. Kev That's clear, ta. But isn't that not how schemas work?
  268. Kev Unless the schema defines an extension point (which it does all over the place for namespaced child elements), you're not allowed to extend it.
  269. ralphm Hence not normative, IMO
  270. Kev It's explicitly normative for 6120, though.
  271. ralphm Hmm
  272. Kev Because it says that you're allowed to validate against it and reject what doesn't match.
  273. ralphm Then I was wrong.
  274. adityaborikar has left
  275. ralphm And I'm unsure if you can add even namespaced attributes to body
  276. Kev Indeed, I think you can't.
  277. adityaborikar has joined
  278. Kev Which I was /not/ expecting.
  279. Kev There's also a question of what 6120 says you can do, and what is sensible to do.
  280. ralphm Right. But on the other hand a much simpler processing model
  281. ralphm Personally, I'd hate seeing new attributes of any kind on elements defined in these schemas
  282. Kev I also think the schema is more restrictive than the text, on allowable stanza errors. IIRC (haven't double checked, but read it earlier) you're allowed your own stanza error elements, but in the schema you have to choose one of the 6120 defined ones.
  283. ralphm But up till now thought it might be ok
  284. Kev At least if I'm reading the schema correctly (not my speciality
  285. Kev ).
  286. Kev ).
  287. Nekit has left
  288. ralphm Ooh, that needs an erratum
  289. Nekit has joined
  290. Kev I also haven't checked the errata. Maybe I should.
  291. ralphm Application specific conditions should definitely be allowed.
  292. Kev Yeah. But a server is allowed to drop stanzas that contain them :D
  293. ralphm I'm not sure if <sequence/> disallows other namespaced elements
  294. Daniel has left
  295. Chobbes has left
  296. Chobbes has joined
  297. Maranda has joined
  298. Daniel has joined
  299. Dele (Mobile) has joined
  300. jmpman has joined
  301. ralphm But I think we should have this explicit.
  302. Maranda https://www.arcgames.com/en/forums/startrekonline/#/discussion/1250600/xmpp-sunset 😭 wiki to rectify soon
  303. ralphm It doesn't say they don't use XMPP going forward, does it?
  304. adityaborikar has left
  305. adityaborikar has joined
  306. ralphm Just that they have issues with their c2s causing spam etc.
  307. Maranda They're dropping
  308. Maranda Support on sept. 19th
  309. ralphm Yeah I read it
  310. jcbrand has left
  311. ralphm I agree just running XMPP internally isn't so interesting
  312. Ge0rG Spam is killing xmpp everywhere. Sigh..
  313. ralphm Lot of negative, insightful, responses
  314. Nekit has left
  315. jcbrand has joined
  316. Nekit has joined
  317. ralphm “This is a feature that enhances many peoples' gameplay, a feature that larger fleets and chat channels are absolutely dependent on, and terminating it demonstrates that Cryptic is shockingly out of touch with the way the players who spend money on their game play it. Don't remove XMPP. Take it out of beta and monetize it instead. Charge $10 or $25 for access if you have to.”
  318. Ge0rG > So that excuse doesn't make sense. Indeed, that looks like an excuse.
  319. adityaborikar has left
  320. ralphm By the way it is for all arcgames properties
  321. Maranda Yes
  322. ralphm Ge0rG: if Google can use that excuse, anyone can
  323. Ge0rG ralphm: it didn't make sense back when Google used it.
  324. ralphm My point
  325. adityaborikar has joined
  326. Maranda They chat system platform is shared across all games originally from Cryptic afair
  327. Maranda Their chat system platform is shared across all games originally from Cryptic afair
  328. Maranda Yes
  329. Maranda > Don't remove XMPP. Take it out of beta and monetize it instead. Charge $10 or $25 for access if you have to.” It's a beta that lasts from 10 years
  330. Seve Not tested enough? :D
  331. Seve That's sad though :(
  332. Maranda Perfect World never expanded or finalised it when they took Cryptic Studios assets
  333. Maranda Seve: indeed
  334. Daniel has left
  335. adityaborikar has left
  336. adityaborikar has joined
  337. Daniel has joined
  338. pdurbin has joined
  339. Chobbes has left
  340. pdurbin has left
  341. aj has joined
  342. jmpman has left
  343. Daniel has left
  344. Dele (Mobile) has left
  345. Daniel has joined
  346. Dele (Mobile) has joined
  347. curen has joined
  348. COM8 has joined
  349. j.r has joined
  350. COM8 has left
  351. Chobbes has joined
  352. Lance has left
  353. Chobbes has left
  354. Chobbes has joined
  355. Chobbes has left
  356. david has left
  357. jonas’ Alex, memberbot does not reply to me
  358. Ge0rG jonas’: can you ping it?
  359. jonas’ oh dear
  360. Chobbes has joined
  361. jonas’ now it does
  362. jonas’ it also appears to have restarted
  363. Ge0rG jonas’: it will restart your "session" if you send presence unavailable or somesuch
  364. sezuan has left
  365. arc has left
  366. arc has joined
  367. jonas’ voted \o/
  368. andy has left
  369. Lance has joined
  370. lovetox has joined
  371. Alex 👍
  372. jonas’ now that bitbucket is sunsetting mercurial, do we need to take action for anything related to xmppoke? or is that fully migrated to github?
  373. Mikaela has left
  374. adityaborikar has left
  375. adityaborikar has joined
  376. Mikaela has joined
  377. COM8 has joined
  378. COM8 has left
  379. Lance has left
  380. COM8 has joined
  381. jmpman has joined
  382. COM8 has left
  383. Chobbes has left
  384. Chobbes has joined
  385. COM8 has joined
  386. COM8 has left
  387. COM8 has joined
  388. andy has joined
  389. COM8 has left
  390. COM8 has joined
  391. COM8 has left
  392. COM8 has joined
  393. COM8 has left
  394. COM8 has joined
  395. Mikaela has left
  396. Mikaela has joined
  397. COM8 has left
  398. pdurbin has joined
  399. Steve Kille has left
  400. COM8 has joined
  401. Steve Kille has joined
  402. Chobbes has left
  403. COM8 has left
  404. lskdjf has left
  405. lskdjf has joined
  406. pdurbin has left
  407. arc has left
  408. arc has joined
  409. COM8 has joined
  410. COM8 has left
  411. COM8 has joined
  412. jmpman has left
  413. COM8 has left
  414. Wojtek has joined
  415. COM8 has joined
  416. COM8 has left
  417. Wojtek has left
  418. patrick has joined
  419. adityaborikar has left
  420. adityaborikar has joined
  421. Nekit has left
  422. Lance has joined
  423. Yagiza has left
  424. Allo has left
  425. Allo has joined
  426. debacle has joined
  427. jubalh has left
  428. jubalh has joined
  429. adityaborikar has left
  430. Dele (Mobile) has left
  431. jcbrand has left
  432. Wojtek has joined
  433. aj has left
  434. Wojtek has left
  435. Dele (Mobile) has joined
  436. Guus jonas’: I think that is all here now, but I'd love for someone with access to the deployment to verify that. https://github.com/xmpp-observatory
  437. pdurbin has joined
  438. Chobbes has joined
  439. jcbrand has joined
  440. j.r has left
  441. Lance has left
  442. pdurbin has left
  443. j.r has joined
  444. Allo has left
  445. Allo has joined
  446. debacle has left
  447. Nekit has joined
  448. marc_ has joined
  449. mimi89999 has left
  450. mimi89999 has joined
  451. neshtaxmpp has left
  452. neshtaxmpp has joined
  453. mimi89999 has left
  454. mimi89999 has joined
  455. Ge0rG mail.jabber.org is still Forbidden.
  456. ralphm Kev said there's been an upgrade, and I think nobody's actually looked into it yet
  457. Ge0rG So did anything happen on the send-presence vs. fetch-MAM vs. receive-offline-messages vs. delete-all-offline-messages front?
  458. waqas has joined
  459. igoose has left
  460. igoose has joined
  461. stpeter has joined
  462. peter has joined
  463. LNJ has left
  464. j.r has left
  465. j.r has joined
  466. pdurbin has joined
  467. mr.fister has joined
  468. david has joined
  469. remko has left
  470. Tobias has left
  471. pdurbin has left
  472. jcbrand has left
  473. peter has left
  474. Chobbes has left
  475. stpeter has left
  476. jubalh has left
  477. waqas has left
  478. wurstsalat has left
  479. eevvoor has left
  480. pdurbin has joined
  481. goffi has left
  482. pdurbin has left
  483. lovetox has left
  484. karoshi has left
  485. Dele (Mobile) has left
  486. david has left
  487. david has joined
  488. Daniel has left
  489. Daniel has joined
  490. UsL has left
  491. Nekit has left
  492. UsL has joined
  493. larma has left
  494. peter has joined
  495. stpeter has joined