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