XSF Discussion - 2019-08-20

  1. Kev

    pep.: he's still doing stuff, as he's always been.

  2. ralphm

    What I mean he doesn't frequent this room, which I thought was what pep. was asking.

  3. pep.

    yeah

  4. eevvoor

    flow why not XMPP for activists? which alternative is there?

  5. eevvoor

    Of course I would use XMPP if I would like to protect myself.

  6. eevvoor

    By the why, activists already use(d) mail :D. Snowden did, and DeltaChat popped up for activist usecase. ^^

  7. jonas’

    all the metadata

  8. Ge0rG

    It's too hard to use properly if your life depends on it

  9. pep.

    That's because "we know". I'm sure others "who know" in other protocols would have other concerns about their solutions :x

  10. ralphm

    Indeed, other protocols have other issues

  11. eevvoor

    until now I cannot see a better protocol than XMPP. Thus I would use it despite my concerns.

  12. eevvoor

    There exists no perfect solution until now.

  13. eevvoor

    Anyhow, you can always use your life if your an activist. ✎

  14. eevvoor

    Anyhow, you can always loose your life if your an activist. ✏

  15. eevvoor

    The enemy comes from all directions. I was always surprised when they appeared.

  16. eevvoor

    :D

  17. ralphm

    I do think that you'd want full control over your server.

  18. Ge0rG

    https://mail.jabber.org/pipermail/standards/2017-August/033123.html is a 401?!

  19. pep.

    Fun

  20. ralphm

    intosi, Kev, MattJ?

  21. Kev

    That'll probably be because of the OS upgrade at a guess.

  22. 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?

  23. Guus

    https://opensource.wearespindle.com/ seems interesting

  24. jonas’

    Kev, I’m not so sure servers restricting the content of stanzas being routed is a good thing

  25. Kev

    It is what 6120 says though - that no entity should be sending out syntactically invalid stanzas.

  26. flow

    Kev, a pointer to the relevant parts of the RFCs would be good idea…

  27. ralphm

    Kev: do you mean unknown namespace prefixes, or unknown attributes without one?

  28. 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.

  29. Kev

    ralphm: Unknown attributes without one.

  30. jonas’

    Kev, content vs. headers

  31. ralphm

    I don't see how that's a syntax violation.

  32. flow

    well message type="nope" is valid IIRC

  33. jonas’

    that, too

  34. flow

    although I would not recommend it

  35. Zash

    Huh

  36. Kev

    flow: no, 6121 enumerates the allowed types.

  37. Kev

    (And 'nope' isn't one of them ✎

  38. jonas’

    Kev, and entities which see an unknown type must (or SHOULD?) treat it as normal ✎

  39. Kev

    (And 'nope' isn't one of them) ✏

  40. jonas’

    Kev, and entities which see an unknown type must (or SHOULD?) treat it as "normal" ✏

  41. Kev

    jonas’: No, that's not right.

  42. 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.

  43. Zash

    Server rejecting `<message><body foo="bar">blah</body></message>` seems totally fine to me.

  44. Kev

    Not that it should accept ones with an invalid type.

  45. jonas’

    Kev, right, I misread that

  46. ralphm

    type='nope' is *not* invalid for Core?

  47. Kev

    ralphm: 6120 references 6121 for its rules.

  48. ralphm

    for IM purposes, yes

  49. 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"

  50. jonas’

    flow, above the enumeration, there is "type MUST have one of those values"

  51. Kev

    flow: You should read the stuff a paragraph or so before as well, which explains it further.

  52. ralphm

    6120 without 6121 is a valid use case. Even XEP-0060 doesn't inherently depend on 6121

  53. jonas’

    Kev, I’m inclined to say, aside from @to and @from, the server should leave routed stanzas alone.

  54. flow

    Well it says something about "if included" the type MUST be one of the following ;)

  55. jonas’

    flow, yes

  56. jonas’

    so it’s either one of the defined ones, or absent. absent defaults to normal.

  57. Kev

    ralphm: That's a good point, thanks.

  58. ralphm

    however, 6120 does have a schema with a restricted list of values

  59. 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

  60. jonas’

    (non-normative schema?)

  61. jonas’

    flow, MUST NOT ;)

  62. Kev

    jonas’: Incidentally (I'd previously missed this) it's OPTIONAL whether a server does the validation.

  63. 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.

  64. flow

    Kev, I still miss the part in the RFC which forbids additional custom unqualified attributes in <body/>

  65. 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.

  66. flow

    (FWIW, I would be happy if such a part exists)

  67. 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 :)

  68. ralphm

    I don't know, think that 8.2.3 ad 5 is pretty convincingly a MUST.

  69. ralphm

    and to me 'not defined' does definitely not mean 'not allowed'

  70. ralphm

    Otherwise the whole idea of ignore what you don't know about, goes out the window.

  71. ralphm

    And rejecting unknown stanza type values is arguably of a different order than unknown attributes.

  72. Kev

    Well, we've always assumed that 'what you don't know about' will be namespaced.

  73. Kev

    But this is all getting a lot muddier than I'd thought it would when I added a ticket for validating syntax.

  74. ralphm

    Kev: I haven't and there are many specs where new attributes, all not namespaced, were added.

  75. jonas’

    which?

  76. ralphm

    pubsub is one

  77. Kev

    I couldn't immediately think of any when I was trying earlier, but thought someone else might be able to, thus asking heer.

  78. Kev

    What does pubsub add?

  79. ralphm

    I mean new attributes compared to earlier versions of the spec

  80. ralphm

    e.g. the publisher attribute

  81. Kev

    Ah. That's somewhat different.

  82. ralphm

    why?

  83. Kev

    They're not adding attributes to RFC-defined elements.

  84. ralphm

    So what if we at some point have a cis and add an attribute to body?

  85. ralphm

    We'd have a mess of older servers that just won't route?

  86. Kev

    I think the argument against blocking the attributes is strong.

  87. ralphm

    I missed the argument?

  88. Kev

    You just made one aspect of it :)

  89. Kev

    But we'd also have to not to anything in cis that was illegal in bis, unless we negotiated cis.

  90. Kev

    Because validation is allowed under bis.

  91. ralphm

    So where is the part that says you can't have other attributes?

  92. Kev

    There isn't one. There is one that say they're not defined, and another that says you're allowed to validate.

  93. ralphm

    The text you quoted doesn't convince me and is not in Core.

  94. Kev

    So it's a little wooly.

  95. Kev

    It's not, but it's referenced from core saying "the rules for this are in -im", or somesuch.

  96. Kev

    I'm sold on not blocking the attributes, though.

  97. ralphm

    wooly indeed

  98. ralphm

    I was kinda curious about the threat model, though.

  99. Kev

    So, different question.

  100. Kev

    Given than 6120 clearly says that servers are allowed to validate syntax, what /would/ be fair game for validation.

  101. Kev

    It seems to be saying you're allowed to validate explicitly against the 6120 schema.

  102. ralphm

    Well, at the very least defined attributes and their values, and indeed things like number of child elements in iq

  103. 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

  104. ralphm

    I think the schema in 6120 is reasonable to check against

  105. Kev

    Oh, this gets messy. If I'm reading it right, the schema is more restrictive than the text, but is normative.

  106. ralphm

    how is the schema more restrictive?

  107. Kev

    Ah, no, this is stream errors, not stanza errors, ignore.

  108. jonas’

    if the schema is normative: absence of any unspecified jabber:client/jabber:server namespaced children

  109. jonas’

    that would show those folks who think they can just drop their XML in there

  110. Kev

    Ah, interesting, so message types are defined in the 6120 schema. Making them restricted even for non-IM.

  111. ralphm

    jonas’: I think the schema language had no way to express this

  112. jonas’

    ralphm, I’m pretty sure that anything which isn’t allowed explicitly in the schema is forbidden?

  113. Kev

    Including undefined attributes? :)

  114. ralphm

    jonas’: why?

  115. jonas’

    that’s how XML schema works?

  116. ralphm

    Kev: on the type values and schema, I mentioned that earlier

  117. 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'?

  118. 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

  119. ralphm

    Is that more clear?

  120. Kev

    That's clear, ta. But isn't that not how schemas work?

  121. 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.

  122. ralphm

    Hence not normative, IMO

  123. Kev

    It's explicitly normative for 6120, though.

  124. ralphm

    Hmm

  125. Kev

    Because it says that you're allowed to validate against it and reject what doesn't match.

  126. ralphm

    Then I was wrong.

  127. ralphm

    And I'm unsure if you can add even namespaced attributes to body

  128. Kev

    Indeed, I think you can't.

  129. Kev

    Which I was /not/ expecting.

  130. Kev

    There's also a question of what 6120 says you can do, and what is sensible to do.

  131. ralphm

    Right. But on the other hand a much simpler processing model

  132. ralphm

    Personally, I'd hate seeing new attributes of any kind on elements defined in these schemas

  133. 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.

  134. ralphm

    But up till now thought it might be ok

  135. Kev

    At least if I'm reading the schema correctly (not my speciality

  136. Kev

    ). ✎

  137. Kev

    ). ✏

  138. ralphm

    Ooh, that needs an erratum

  139. Kev

    I also haven't checked the errata. Maybe I should.

  140. ralphm

    Application specific conditions should definitely be allowed.

  141. Kev

    Yeah. But a server is allowed to drop stanzas that contain them :D

  142. ralphm

    I'm not sure if <sequence/> disallows other namespaced elements

  143. ralphm

    But I think we should have this explicit.

  144. Maranda

    https://www.arcgames.com/en/forums/startrekonline/#/discussion/1250600/xmpp-sunset 😭 wiki to rectify soon

  145. ralphm

    It doesn't say they don't use XMPP going forward, does it?

  146. ralphm

    Just that they have issues with their c2s causing spam etc.

  147. Maranda

    They're dropping

  148. Maranda

    Support on sept. 19th

  149. ralphm

    Yeah I read it

  150. ralphm

    I agree just running XMPP internally isn't so interesting

  151. Ge0rG

    Spam is killing xmpp everywhere. Sigh..

  152. ralphm

    Lot of negative, insightful, responses

  153. 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.”

  154. Ge0rG

    > So that excuse doesn't make sense. Indeed, that looks like an excuse.

  155. ralphm

    By the way it is for all arcgames properties

  156. Maranda

    Yes

  157. ralphm

    Ge0rG: if Google can use that excuse, anyone can

  158. Ge0rG

    ralphm: it didn't make sense back when Google used it.

  159. ralphm

    My point

  160. Maranda

    They chat system platform is shared across all games originally from Cryptic afair ✎

  161. Maranda

    Their chat system platform is shared across all games originally from Cryptic afair ✏

  162. Maranda

    Yes

  163. 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

  164. Seve

    Not tested enough? :D

  165. Seve

    That's sad though :(

  166. Maranda

    Perfect World never expanded or finalised it when they took Cryptic Studios assets

  167. Maranda

    Seve: indeed

  168. jonas’

    Alex, memberbot does not reply to me

  169. Ge0rG

    jonas’: can you ping it?

  170. jonas’

    oh dear

  171. jonas’

    now it does

  172. jonas’

    it also appears to have restarted

  173. Ge0rG

    jonas’: it will restart your "session" if you send presence unavailable or somesuch

  174. jonas’

    voted \o/

  175. Alex

    👍

  176. 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?

  177. 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

  178. Ge0rG

    mail.jabber.org is still Forbidden.

  179. ralphm

    Kev said there's been an upgrade, and I think nobody's actually looked into it yet

  180. Ge0rG

    So did anything happen on the send-presence vs. fetch-MAM vs. receive-offline-messages vs. delete-all-offline-messages front?