XSF Discussion - 2020-05-23

queen_tilfaar: this server does federate, what do you mean

Anybody got clues on how xsf/registrar works?

Figured it out! Don't touch it. Update the XEP

Hi MattJ, have you found some time to check about the access?

https://github.com/xsf/xeps/pull/950

> queen_tilfaar: this server does federate, what do you mean Alright let's test this. Let's see if this message goes through

Nope can't do I have to enable this server exclusive account to chat

I hope this is a bug

Hi, is there any prior work to using 0059 in 0004 data forms?

0004 has its own pagination thing iirc?

You can do pagination in 0050 by just having an option "Next" which loads a new form with the next page. I am pretty certain I've seen that somewhere already.

Zash, I can’t find that.

Link Mauve, probably confusing it with the <reported> stuff then

But yes, <reported/> is what I’d like to have 0059 for.

larma, thats not pagination

thats the next command stage in a multi stage flow

of course you could misuse this as pagination

but it was not intended that way

and it would break every adhoc command dialog

Link Mauve, xep141

flow, hmm, that’s not exactly my usecase: imagine I retrieve a <reported/> with a huge lot of items, which doesn’t fit in one stanza, how can I page through them similarly to in 0055 results?

lovetox, I guess you misunderstood. in ad-hoc if server sends a form where you need to pick one entry from a list, there was one entry "<previous>", one entry "<next>" and about 20 actual entries. If I pick any of the 20 actual entries and then execute next I'd do certain action, if I pick "<next>"/"<previous>" entry and execute next I'll get another form. I think Gajim was handling this perfectly fine and I don't see why that would be misuse or break typical ad-hoc implementations. It obvious was terrible UX, but that's something you get used to when using ad-hoc

Link Mauve, is this pure xep4 or with ad-hoc?

flow, with ad-hoc.

(How is it different?)

larma, in Adhoc "Next" means always next stage ✏

there is no next page, and there is no difference between execute and next

Link Mauve, I wonder, like lovetox, if you could then use stages

ad-hoc command stages that is

flow thats bad, he wants to return a huge list

I am not sure if xep4+rsm is a good idea

lovetox, why is it bad?

So, my usecase is that a user wants to list what they have uploaded using 0363, ignoring all usecases where the deployment might have already deleted some or whatever.

because thats not how adhoc works, you dont display pags of data in different stages

To then implement e.g. a photo album, or the ability to delete one of these files.

Link Mauve, maybe grouplist the result list items in multiple stages works

That sounds like a hack. :/

lovetox, so you saying it can't be done with ad-hoc commands?

Link Mauve, not sure, but that use case sure is worth considering

Link Mauve, I assume an "upload" is modelled as multiple fields? or are multiple uploads the values of a single field?

flow, I was thinking of one item per file, with multiple fields as the implementation sees fit.

(And has available.)

ahh right xep4 has <item/>

Could you model it as a disco#items list on a special node + ad-hoc command on each node?

I wonder if there is prior art in user search

surely user search could return a large result set

https://xmpp.org/extensions/xep-0055.html ^F 0059 → no hits

Zash, 0059 ^F 0055 though describes the protocol.

Haha

Backwards

Feel free to migrate it to 0055 if you care enough. :p

well then it may be worth specifying something like rsm for xep4, which should be negoiatable, as in requestor adds flag to request, responder replies with rsm-is xep4 response

Zash, so in your proposal, a client would disco#items like in XEP-0135, and do ad-hoc commands there?

That sounds bad if e.g. you want to select many files and delete them at once.

flow, yup.

Zash, that eventually only shifts the large result set problematic from xep4 to xep30, no?

Hmmmmm

I mean, i really like to see rsm disco going

flow, RSM does specify itself for both 0055 and 0030.

I think I even have a commit or even made a pr in that regard

(Backwards again, I guess.)

Link Mauve: It would move that into the client and make it less efficient to batch-delete stuff.

Only one of the existing four deferred XEPs for file management deals with deletion, and it does it only for deletion notifications (XEP-0214).

larma, flow : i was wrong, yes pagination is ok if the adhoc command does only list things

Link Mauve, ahh right

problem is what Link Mauve wants is, list things, then select things, then delete things

so it would be exceptionally bad, if you have to page through 1000 items, only to come to the last command stage

where you finally can delete them

lovetox, maybe you can have an optional field where you select the items to delete that are currently displayed?

and then 'next' not only shows the next page, but deletes the items you have selected (if any) ✏

Select action first, page through list and select items, finalize?

Or select items first, then action?

🤷️

no i just reread 0050

even that is possible

a stage can have a next action and a complete action

so the only not nice thing now is, that a generic adhoc UI would not be able to display all items on the same page

and thus unable to provide any search/sort capabilities

You could probably do that over ad-hoc as well, but it'd probably be very awkward

https://larma.de:5281/upload/l6Awnt59kxp4xga9/just_pick_next.png

larma, i was wrong, a stage can have "next" and "complete" buttons

so you can say, delete, and next page

no need for that workaround

I am not saying that there is no better way, but this is what I've seen before, and it certainly does work

and probably is compatible with every client

even those not implementing the action to move to previous page

Is there anything about "A hidden field named FORM_TYPE" saying it's special?

There was discussions about that not so long ago right?

Yes

https://xmpp.org/extensions/xep-0068.html

Thanks

So, in BOSH, what should happen on stream error?

I tried to log in with an invalid password, received <body sid="507521e3-75ea-47e6-af62-8e746ea8d2d0" xmlns="http://jabber.org/protocol/httpbind" xmlns:stream="http://etherx.jabber.org/streams"><failure xmlns="urn:ietf:params:xml:ns:xmpp-sasl"><not-authorized/><text>The response provided by the client doesn&apos;t match the one we calculated.</text></failure></body>

Wait, that's not a stream error

That's a SASL error. Those are not fatal, you're free to try again.

Oh, I see.