XSF Discussion - 2019-08-05

Is there any description of transport negotiation for https://xmpp.org/extensions/xep-0338.html ?

I guess it's like 1) all content element in group MUST describe the same transport 2) an implementation should assume 1 and take any to start negotiating. 3) during transport negotiation it doesn't matter which content name in group is used for transport-info messages 4) after the transport is negotiated all the content in group is considered to be ready to transfer data.

https://tools.ietf.org/html/rfc6120#section-4.7.3 -- do we have any good reference for the "random and non-repeating" requirement for the stream id? I'm fairly sure we didn't come up with it ourselves

it sounds like uuid v4 or something

i recall "take the timestamp and add something random" in that context. but not sure from where. maybe dwd remembers?

fippo: that sounds like uuid v1 and v2

marc_: ping. Do you have short-/mid-term plans to work on XEP-0401?

Ge0rG: I'm at a point where it would be nice to meet with other people to discuss how to integrate this feature for good UX

meet? like, in meatspace?

marc_: then you should go to a Sprint.

Also, if we should rely on PARS and so on

marc_: I feel that the unfinished state of 0401 is distracting people from implementing it

s/distracting/detracting/?

deterring.

I have very strong opinions regarding PARS.

Ge0rG: what opinion?

marc_: PARS is a very good fit for the use case.

Ge0rG: yes, for this kind of discussion "we" need to meet in person

Ge0rG: why do you ask?

marc_: Are you coming to FrOSCon? That will be probably the only chance in the next months.

marc_: other than that, email / xmpp should do it.

marc_: and I'm asking because one day, The Editor will realize that it's actually Deferred by now.

Don't say it too loudly

Ge0rG: I don't know when is FrosCon?

oh right, I forgot to run The Script

this weekend

Then I'm not at Froscon 😄

marc_: I want to finally make 0401 usable, and integrate it in the next yaxim release.

Ge0rG: do you know if somebody else is interested in this feature?

marc_: Anu from Monal is interested in easier user onboarding, and I'm sure we'll find more non-stubborn people

Ge0rG: what's your timeline?

I'd also like PARS tbh, but just IBR in poezio is a pain (in slix actually)

pep.: pars != ibr

pep.: maybe I don't get what you want to say

marc_, yeah ok not 401, but IBR does count into onboarding

hmm, 401 does mention ibr

Yes, but pars is without ibr

I would prefer 401 without pars at all

https://xmpp.org/extensions/xep-0401.html#redeem-no-account

Also https://xmpp.org/extensions/xep-0401.html#preauth-ibr

pep.: 401 has ibr but pars doesn't

Ah sorry I was confused, PARS is not 401 indeed

Or let me rephrase: I would like to have 401 with a single use-case without fallback, different UX and so on

marc_: what are the UX inconsistencies you see currently?

Ge0rG: different behaviour when the Server does not support 401 or ibr

marc_: I'm very sure those can be hidden from the users, except obviously when a server supports neither, in which case you are lost.

Is there a prosody module for all that btw?

Ge0rG: no, you have to choose a server, create a regular account when ibr is not allowed

You cannot hide this

pep.: no, not for 401

marc_, the client can abstract some of it still. At least the choice of server can be really oriented

pep.: how?

By using a default one?

Choosing one depending on $stuff, (user language, location, etc.?)

marc_: have you seen the yaxim onboarding?

marc_: are you saying that it's better to fail immediately than to provide graceful fallback?

No, I would say "invite" is invitation on a server. Everthing else is adding a contact

Then it is clear what will happen

marc_: but the user wants to get both in one step

A user doesn't care what kind of tech magic is behind, they want a simple and fast onboarding

Ge0rG: create account + mutual subscruption of couree

marc_: I'm just saying that it makes very much sense to use the same PARS mechanism for the out of band invitation transmission

Ge0rG: however, I would split add contact (with server pars) and account invite

marc_: but why?

But the UX changes if ibr is not supported

And different UI for the same "invite" sucks

Different UI because some tech stuff in the background is different sucks IMO ✏

marc_: what's different about the UI?

(Not) able to create an account, as said before

marc_: the difference is what comes behind the @ in the dialog.

Yes, sometimes you have to choose a server

You as the invitee should always be able to choose the server.

And still send up with your friend added

Yep, at least when you add a contact

No, always.

But that's what needs to be discussed :)

You don't need 0401 for manually adding friends

Yep, you need it for account creation and server-side pars

marc_: that reads like we agree

marc_: and I was asking because 0401 needs some text improvements, and I wanted to step up

Ge0rG: I don't know if we agree but would be nice if you discuss 401 with other xmpp guys at froscon

Ge0rG: I really would like to see some movement on 401

I think At the end of this month I have time to work on it

marc_: are there still text improvements to be made?

Ge0rG: in 401? Of course, there are even some TODOs IiRC

marc_: because that makes it hard to pitch it to developers

You can not pitch it, just pitch the idea :D

marc_: and they will ask for the XEP

XEP is not a big deal once all agree on the same user story / use case

Ge0rG: what's the timeline for the next yaxim release

marc_: I have no idea, sorry.

Ge0rG: okay, sounded like you plan a release in the next few weeks :)

marc_: no, but other developers do