XSF Discussion - 2020-03-25


  1. oxpa

    guys, any chances xmpp.jp admins are here? I have troubles reaching conference.xmpp.jp from jabber.ru and find out what the problem is.

  2. oxpa

    or may be you can ask xmpp.jp guys contact me through twitter or directly at oxpa@jabber.ru?

  3. Ge0rG

    oxpa: Contact Info> admin: mailto:support@xmpp.jp https://www.xmpp.jp/contact abuse: mailto:support@xmpp.jp https://www.xmpp.jp/contact support: mailto:support@xmpp.jp https://www.xmpp.jp/contact

  4. Ge0rG

    oxpa: if you have trouble contacting them via s2s, they will have trouble contacting you as well ;)

  5. oxpa

    no-no, s2s works per se. I can contact any user@xmpp.jp. Only conferences 'behave'

  6. oxpa

    also, i wrote aletter to support@xmpp.jp - no luch

  7. oxpa

    also, i wrote aletter to support@xmpp.jp - no luck

  8. moparisthebest

    I hate asking this... does anyone know of a facebook messenger transport? I of course tried searching but can only find articles about facebook turning off XMPP support years ago

  9. pep.

    nothing in libpurple?

  10. Ge0rG

    Last time I used spectrum2

  11. moparisthebest

    ah may be https://github.com/dequis/purple-facebook/wiki "Protocol: Facebook (NOT Facebook (XMPP))"

  12. moparisthebest

    that was another problem, every time I found some integration, it was XMPP based, which no longer works :'( terrible

  13. moparisthebest

    facebook has a newish "kids messenger" app that uses the parent's facebook for access control, and wife keeps getting invites for my kids, meanwhile I haven't had much traction in "just have them install Conversations instead" department :'(

  14. Zash

    Snikket?

  15. moparisthebest

    3.

  16. moparisthebest

    oops, well it's main features appear to be "stickers" and "video chat with stupid overlays" with text chat way down on the list, not sure if XMPP can compete in those departments

  17. Zash

    Of course not

  18. moparisthebest

    mainly XMPP is lacking in the "creepy spying and data collection by facebook" department though

  19. Daniel

    When I configure something via data forms. For example a muc or a pubsub node. And I send an incomplete data form. Will the missing fields be left untouched or configured to the forms default?

  20. MattJ

    Guess

  21. MattJ

    and whatever you guess, we can document

  22. MattJ

    ;)

  23. MattJ

    I'm not aware of any text around this, I think it probably depends on context, but I wouldn't rely on it being the same across implementations

  24. MattJ

    The "depends on context" thing comes from the fact that I believe XEP-0004 primarily grew out of a protocol that was designed for presentation

  25. MattJ

    rather than machine-to-machine configuration

  26. larma

    apropos data forms: In XEP-0068 it says that "If the FORM_TYPE field is not type="hidden", it does not have the special meaning defined herein." and "If the FORM_TYPE field is not hidden, it MUST be ignored as a context indicator.". In XEP-0004 it says that "For data forms of type "submit", inclusion of the 'type' attribute is OPTIONAL". So, for data forms of type "submit" it still seems to be required to add the type="hidden" for FORM_TYPE according to XEP-0068, yet most clients seem to not send it and most servers seem to ignore that - and many XEPs also don't do it accordingly in their examples. Should we note in XEP-0068 that specifying type="hidden" is optional in forms of type "submit"?

  27. lovetox

    on this occassion i want to point to issue 1511 !

  28. lovetox

    :D

  29. MattJ

    Ha, I missed that

  30. lovetox

    Daniel, but how would you come into this situation, do you want to reduce traffic and not requesting the Data Form from the server? rather just send a incomplete one where you know some fields will probably be supported?

  31. Zash

    1511 in what repo?

  32. Daniel

    lovetox: the library I'm using weirdly doesn't have a method to submit a form / and or change only one specific value in a previously downloaded form

  33. Zash

    How about a left-out field preserves the existing value, or the default in case you're creating something.

  34. Zash

    Now let's discuss (nothing) vs <field/> vs <field><value/></field>

  35. lovetox

    Zash a issue on your tracker

  36. Zash

    Ah that

  37. lovetox

    but since you include a register fields as backup for clients that dont support dataforms, i guess this issue was not discovered until now :)

  38. Zash

    Isn't this more on-topic in the Prosody roomq

  39. Zash

    s/q/?/

  40. lovetox

    oh damn

  41. lovetox

    i thought i was in the prosody room

  42. lovetox

    because i saw you and mattj :D

  43. lovetox

    sorry for the offtopic

  44. flow

    larma, I'd love to discuss this but failed to follow the question

  45. flow

    what in xep68 makes type=hidden required in submit?

  46. larma

    0068 says that FORM_TYPE does not have any meaning and MUST be ignored as a context indicator if it's not type=hidden. Thus when submitting a form, adding FORM_TYPE without type=hidden is same as not adding it.

  47. Zash

    This seems silly somehow

  48. larma

    agree, my suggestion would be that we state in 0068 that in forms with type='submit' the field type='hidden' is optional

  49. larma

    because that's what we do in practice anyway ๐Ÿ˜‰

  50. larma

    it's also codified in examples in many XEPs

  51. Zash

    Fine with me. PR it?

  52. Zash

    types being optional in type=submit forms is funky in its own ways

  53. flow

    Tbf I still don't see the issue, but if you agree on it and maybe the PR makes it clear

  54. flow

    Zash, why?

  55. flow

    (assuming you are talking about FORM_TYPES?)

  56. Zash

    Context of https://xmpp.org/extensions/xep-0128.html

  57. Zash

    Oh those are result

  58. larma

    great, so it's invalid form according to 0004 ๐Ÿ˜‰

  59. Zash

    flow: Imagine you get a form with a bunch of <field>s, none of which have type set. Fields can have 0, 1 or more <value>s.

  60. Zash

    > For data forms of type "submit", inclusion of the 'type' attribute is OPTIONAL, since the form-processing entity is assumed to understand the data types associated with forms that it processes.

  61. Zash

    Sensible

  62. larma

    yes, it's ok for submit, not for any other forms

  63. Zash

    So .. no problem then?

  64. flow

    (ignore me)

  65. larma

    well, xep 0068 overwrites that part of 0004 by saying that if it doesn't have type='hidden' it shall not be considered as 0068 FORM_TYPE

  66. flow

    ahh I think now I got what larma means

  67. flow

    but for submit the FORM_TYPE can be ignored by the receiving entity anyways

  68. flow

    is that I would assume

  69. larma

    it might be, yes

  70. larma

    but then it is also optional to send it

  71. larma

    and I don't think that's the case in all scenarios either

  72. flow

    probably true

  73. larma

    https://xmpp.org/extensions/xep-0045.html#requestvoice

  74. flow

    the question is if there is a link to the previous form somewhere in the outer shell of the submited form

  75. larma

    ^ relies on FORM_TYPE = "http://jabber.org/protocol/muc#request" yet doesn't set type='hidden'

  76. Zash

    larma, but type=submit and the form is supposed to be understood by the receiver

  77. lovetox

    not sure why the form type can be ignored in a submit form, does this assume all forms are only sent as IQ and the server is able to track what context the form has?

  78. flow

    Zash, how can the receiver identify the form if he is supposed to ignore FORM_TYPE?

  79. Zash

    Tho it makes it tricky if you want to add more kinds of those flows

  80. lovetox

    what if someone sends me a form as message, and i send the form back as message

  81. lovetox

    how would the receiver ever get the context of the form?

  82. flow

    lovetox, in general they can be tracked, but larma just provided an counterexample

  83. lovetox

    not as message, the receiver would have to place some hidden tracking id into the form

  84. lovetox

    also a message allows for multiple forms in the same message

  85. Zash

    Hm, how did we implemente that

  86. flow

    Zash, probably by looking at FORM_TYPE (and not following the strict interpretation of xep68 ยง 4.3)

  87. lovetox

    larma, thats clearly a error in the example

  88. larma

    flow, to be fair, according to XEP 0045 the only form that you can send by message is the voice request form, still that would be rather crazy code to assume all message[type=normal]+form[type=submit] to a muc bare jid is to be considered a voice request or approval

  89. flow

    larma, yep

  90. larma

    and I bet servers do check the FORM_TYPE ๐Ÿ˜‰

  91. Zash

    Yup, it checks the FORM_TYPE

  92. flow

    lovetox, besides that there a probably more examples like these in the xep, i'd also assume that this is typical behavior in the wild

  93. flow

    bbl

  94. larma

    Zash, and also accept it when not having type='hidden' I assume?

  95. lovetox

    hm what do you mean, i get many forms i never saw a server send me formtype with type != hidden

  96. lovetox

    that would obviously result in the client showing this field to the user

  97. lovetox

    because its not hidden

  98. lovetox

    really i impl forms since years and we have many workflows with forms, and this never ever happend even once

  99. lovetox

    so not buying that argument that people dont set the type in the wild

  100. Zash

    larma: Yeah it ignores the type.

  101. lovetox

    and this rule make sense

  102. lovetox

    if its no hidden, its presented to the user

  103. lovetox

    as editable field

  104. lovetox

    this means he could change the context on the submit

  105. flow

    larma> agree, my suggestion would be that we state in 0068 that in forms with type='submit' the field type='hidden' is optional +1

  106. larma

    lovetox: this is only about forms with type=submit, which you normally don't display in user interfaces

  107. flow

    FORM_TYPE feels like a displaced hack anyways. I wonder why do don't have a form-namespace attribute in <{jabber:x:data}x/>

  108. Zash

    When does a server even look at a form of any type but submit?

  109. larma

    lovetox, You display type=form and type=result and in those it should still be required to have it hidden because we don't want to display it to users

  110. lovetox

    but what you now are saying, type submit is never shown in a GUI

  111. lovetox

    can we make that assumption?

  112. Zash

    Sending a type=submit form to someone that was not expecting it .. seems unlikely to me

  113. lovetox

    ok but there is a type=result

  114. Zash

    And if they're expecting it then they should already have the form locally, and thus know the form type

  115. Zash

    type=result require <field type=...> right?

  116. lovetox

    hm no when i read it correctly

  117. lovetox

    only form needs type

  118. lovetox

    everything else MAY include types

  119. lovetox

    and submit its OPTIONAL

  120. Zash

    Mabye it needs to be clarified that you would never send a from type=submit to an entity that doesn't already know what the form looks like

  121. lovetox

    i scrolled back but i dont get how or where this is a problem, how did this question get raised?

  122. Zash

    Normal flow would be that I send you a form-from, then you return a submit-form, and I give you back a result form.

  123. Zash

    flow: Agree on the hacky feeling.

  124. Zash

    Inconsistent to include the field type on the other field in https://xmpp.org/extensions/xep-0045.html#example-80

  125. larma

    http://www.aptest.com/standards/htmldiff/htmldiff.pl?oldfile=https://xmpp.org/extensions/xep-0068.html&newfile=https://larma.de/xeps/xep-0068.html

  126. Zash

    ๐Ÿ‘๏ธ