XSF Discussion - 2020-03-25

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.

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

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

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

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

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

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

nothing in libpurple?

Last time I used spectrum2

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

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

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 :'(

Snikket?

3.

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

Of course not

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

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?

Guess

and whatever you guess, we can document

;)

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

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

rather than machine-to-machine configuration

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"?

on this occassion i want to point to issue 1511 !

:D

Ha, I missed that

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?

1511 in what repo?

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

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

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

Zash a issue on your tracker

Ah that

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

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

s/q/?/

oh damn

i thought i was in the prosody room

because i saw you and mattj :D

sorry for the offtopic

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

what in xep68 makes type=hidden required in submit?

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.

This seems silly somehow

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

because that's what we do in practice anyway 😉

it's also codified in examples in many XEPs

Fine with me. PR it?

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

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

Zash, why?

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

Oh those are result

great, so it's invalid form according to 0004 😉

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.

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

Sensible

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

So .. no problem then?

(ignore me) ✏

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

ahh I think now I got what larma means

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

is that I would assume

it might be, yes

but then it is also optional to send it

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

probably true

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

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

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

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

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?

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

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

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

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

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

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

also a message allows for multiple forms in the same message

Hm, how did we implemente that

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

larma, thats clearly a error in the example

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

larma, yep

and I bet servers do check the FORM_TYPE 😉

Yup, it checks the FORM_TYPE

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

bbl

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

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

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

because its not hidden

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

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

larma: Yeah it ignores the type.

and this rule make sense

if its no hidden, its presented to the user

as editable field

this means he could change the context on the submit

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

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

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

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

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

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

can we make that assumption?

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

ok but there is a type=result

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

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

hm no when i read it correctly

only form needs type

everything else MAY include types

and submit its OPTIONAL

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

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

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.

flow: Agree on the hacky feeling.

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

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

👍️