XSF Discussion - 2020-02-26

This is especially annoying if you are on mobile (*)

only if you have functions enabled which are designed to make your life harder by taking control away *scnr*

Is there any reason why you couldn't include a form in the first step of an ad-hoc command? https://xmpp.org/extensions/xep-0050.xml#execute-simple

Assuming you know ahead of time what the form looks like, eg because it's standardized by xep-0133 or such

Zash, you could try, and I guess any sane service would allow it (because if it isn’t stateless, you run into fun DoS opportunities)

Just got rid of a thing in a convenience wrapper for simple commands that required that one-step commands be stateful.

hi, the `source control` link from `https://xmpp.org/about/standards-process.html#submitting-a-xep` points to `https://xmpp.org/about/xsf/xsf-source-control/` (which 404s) and should point to `https://xmpp.org/about/xsf/source-control.html`. I forked the repo and tried to test it locally but the dev server from isn't rendering the menu, don't know why. I think a plausible fix might be ```diff --git a/content/pages/about/standards-process.md b/content/pages/about/standards-process.md index 303616b..38d8bc1 100644 --- a/content/pages/about/standards-process.md +++ b/content/pages/about/standards-process.md @@ -34,7 +34,7 @@ Here's how to submit a proposal to the XMPP Standards Foundation for considerati 2. Make sure you read, understand, and agree to the XSF’s [IPR Policy](/about/xsf/ipr-policy) before you submit your proposal! 3. Email the XML file (or a URL for the file) to the [Editor Team](mailto:editor@xmpp.org) with a subject line of "ProtoXEP: [your title here]". -Note: It is the author’s responsibility to provide a properly-formatted source file (see the [template](/extensions/xep-template.xml) file maintained under [source control](/about/xsf/xsf-source-control/)). Proposals submitted in HTML, TXT, MS Word, Open Document Format, etc. will be returned to the proposal author for proper formatting. +Note: It is the author’s responsibility to provide a properly-formatted source file (see the [template](/extensions/xep-template.xml) file maintained under [source control](/about/xsf/source-control.html)). Proposals submitted in HTML, TXT, MS Word, Open Document Format, etc. will be returned to the proposal author for proper formatting. #### Editor creates a ProtoXEP ```

also, the `xep-template.xml` file doesn't exist in the website repo, should it be linked to the raw version from the xeps repo maybe (https://raw.githubusercontent.com/xsf/xeps/master/xep-template.xml)?

marc0s: the dev server doesn't render the menu for me either :(

jonas’, thanks for the feedback

marc0s: linking to the xeps repo sounds sane to me

go ahead and make a PR against xmpp.org

thank you

It also needs some updating, the dev server, as `python -m pelican.server` no longer works, at least with debian's packaged `pelican`, needed to use `pelican --listen`

jonas’, I will then

yeah there are a few issues that could use some fixing on the website with newer python

Regarding XEP-0313 deferred, please don't LC it

I have an update incorporating existing feedback that I already received

I posted this quite some time ago to people who inspired the feedback, I don't think I got any responses and I didn't follow-up

But given the XEP is widely implemented already I didn't want to just push the changes without agreement that they were sensible

I can dig up what I had done and post it to standards@ or something, or if people think I should just push it as a new revision I can do that

MattJ, please do that

Which? :)

the posting to standards@

Sure

I wasn’t finished reading the message when I replied :D

also, I thnik I’m one of those you pinged and I totally forgot about that and I’d love to check your changes.

Here's a diff I generated: https://matthewwild.co.uk/uploads/stdin-s2ilB8Kj

I can dig up the XML from whichever checkout I had it in

i see before-id/after-id fields

I love it already

{+ <field type='text-single' var='urn:example:xmpp:free-text-search'/>+}

sugegstion: make this {clark}notated

MattJ, I have a bit more of feedback on this, shall I dump it here or 1:1?

If it's brain-dump style... an email? (i.e. TODO item for me)

if it's interactive, I'm fine with here or 1:1

brain dump

email == jid?

Email or 1:1 and I'll copy/paste it somewhere :)

Sure

sent

Received, thanks!

I'll aim to act on that by the end of next week

that sounds amazing

Still without an office, and my work schedule is suffering :)

Question to the server developers. I'm assuming that by now you are all treating muc presence with the x user attribute as full joins. To you remember when you started doing so?

With what version of your respective server software

Wondering if it is time to remove the good old leave before join work around

Looks like it was Prosody 0.11 when we started rejecting GC 1.0 joins

So 2018-11-21

There are still many pre 0.11 in the wild

Got stats?

Ask jonas

I only have anecdata of Debian oldstable

Debian stable has 0.11, oldstable-backports has 0.11, normal support for oldstable likely ends this year

IMHO usually the ideal point in time to drop compatibility workarounds or older protocol versions is when its about 2 years after the point in time when you should have dropped them

So when do we drop the "MUST support GC 1.0" from XEP-0045?

now that is something we could drop

Zash, it appears Smack removed GC 1.0 in 2006

Wait, did Ge0rG and I sneakily remove that MUST already or did I imagine it?

flow [21:12]: > IMHO usually the ideal point in time to drop compatibility workarounds or older protocol versions is when its about 2 years after the point in time when you should have dropped them May I quote that in https://discourse.igniterealtime.org/t/smack-android-api-requirements/85767

Zash: > Therefore, starting with version 1.32 of this specification, it is RECOMMENDED that a service receiving a <presence> without an <x> element from a non-occupant full-JID responds with an explicit kick to that client.

Not only we removed the requirement to support GC1.0, we even discourage its use

Ge0rG, the latest release version of Smack requires Android API 9 or higher, and Android API 9 is Android ~10 years ago

the upcoming version will bump to Android API 19, which is Android 4.4 released 7 years ago

so I believe to be reasonable conservative when it comes to supporting old versions

Ge0rG, \o/

flow: yes, and now just add two more years...

Ge0rG, already did so two years ago ;)

I think i have roughly a dozen patches on top of 4.3 now, either adding new features / XEPs, or providing access to internals which I need exposed, or working around real world implementation issues, like the Dino MUC

flow: two years ago it was too early!

Ge0rG, you have the same problem with 389 as with regular IBR, right?

tbh, I don't see much advantage of 389 at all

marc: no, I see a number of additional problems in 0389

proof-of-work just won't work against spammers

yep

Okay, maybe we can split 401 and PARS but somehow reference them as Daniel suggested (?) and we're done? :)

marc: I think that a split doesn't make sense. Not for the UX and not technically

Ge0rG, okay, but why didn't you respond to the mail then?

I see a big advantage in easy account creation

PARS on top is nice but not a must

You don't have to add the contact from 0401. You could also add everybody who used the same token, like with the snikket Demo

But those are not the main use case

The really important case is adding a friend and having them in the roster automatically

Daniel also made a bet on using the phone address book to automatically add contacts.

My impression is that he considers this bet as failed now

If you remove PARS from 0401, you'll end up with implementations that allow registration from an invitation token, but don't consistently add the contact, so you don't gain much

Alternatively, you could move the combined functionality into a third XEP, but what would be the benefit?

To be fair half the implementations do that already

Daniel, hm?

do what?

Implement the registration part but not the contact part

Daniel, what exactly did you implement from 401, btw?

The being 'invited' to a server part

And use the pars token to register

Daniel, this means you send the token via ibr to the server?

Yes

Daniel, via IBR or IQ?

Well the weird pre ibr thing

:-(

I don't have any feelings on that

I hate it ^^

That was just what's supported by prosody

> marc: I think that a split doesn't make sense. Not for the UX and not technically Ge0rG, I'm also in favour of spliting the two processes. As a UX developer you want the user to get some sort of image of how the application works. And for "getting a contact into your roster", I'm trying to teach the user that this happens by clicking some specific button(s). If you now start to just magically add contacts to the contact list, you break the image I'm trying to convey. What I'd like to do is to add the contact and then perhaps display a dialog "Anna invited you, would you like to add her?". I know you want to make the whole process easier, but adding more concepts doesn't make understanding easier.

lskdjf, good point

I think I said this on list but my interest in the registration part is to avoid open ibr for semi public servers (read hacker space, club) where you can stick a qr code on the wall and everyone who has physical access to the building can sign up. But spammers can't

s/What I'd like to do is to add the contact/What I'd like to do is to add the account

I don't agree at all with the concept of so called easy xmpp

lskdjf: that's interesting indeed. But then would you also introduce the concept of presence subscription and its bidirectionality?

Which is fine. There can in fact be xeps that I don't agree with

But I don't like to loose what in my eyes is a valid use case

Daniel: the hacker space functionality is there, just use the domain JID URI

Daniel, sure, my primary use case is a similar one

Hackerspace functionality whatnow?

It's even implemented in yaxim and prosody already

Daniel, and sure, you don't have to agree on everything but I would like to have opinions from experienced devs

Zash: > I think I said this on list but my interest in the registration part is to avoid open ibr for semi public servers (read hacker space, club) where you can stick a qr code on the wall and everyone who has physical access to the building can sign up. But spammers can't

I know that it is covered. Conversations handles that. But it is a mess to comprehend due to the tight coupling with _shit I don't need_

Ge0rG, ah, ours was set up to limit registrations to the local IPv6 network

Daniel: but it might be shit that your users need...

Everyones needs are different for some weird reason.

What _shit_ are you talking about?

Well the registration part hooks (at very least semantically) on pars

Which by its name alone is something completely different

> lskdjf: that's interesting indeed. But then would you also introduce the concept of presence subscription and its bidirectionality? Ge0rG, depends on the application and how detailt the picture is they convey. The easier version would probably be to say that if "contact X on your roster/friend list" == "contact x gets your information"

I could very well live with changing 0401 to "if the invitation is from a user bare JID, the receiving client shall perform a roster request with the token as a PARS token. The client may first ask the user for permission / guide them through the process"

Would that satisfy Daniel and lskdjf?

I actually read my email again and I think it brings my point across

You say you don't want to separate the two because you are afraid someone will implement the registration without the subscription part

I don't think that's something the xep author should decide

Right, the main reason for the XEP should be optional.

Hm, what about less irony and more constrictive input? 🤔

Since there is no good argument against IBR, I would like to keep this as-is, or is there a good argument?

Seems like I should have participated in this discussion, but I didn't see it was happening

I don't care much about the protocol - if people don't like the iq thing, come up with something else

I think the argument about making the user do more work to add a contact they want to speak to, just to teach them a lesson is... not sound

We already know the user intent, don't add more clicks or taps than we need to get the task done

They can learn to add contacts next time they want to add a new contact

Getting someone onboarded to the network is enough work already

We need to remove all the friction we can

"just to teach them a lesson" I can only read this in a pejorative way, is it how you mean it?

Read it however you want :)

I don't think that's how lskdjf meant it anyway :)

To teach the user habits, patterns

It doesn't matter, it's what it is doing

You want to talk to a contact, but first we want you to go through some training

MattJ, no you got it in reverse

to teach the user a lesson we need to implement a XEP I've always dreamed of "remote slapping of a user over the internet"

if you allow that to be one and only step, then next time they want to add somebody they'll be like "why did I have to do something this time?"

That's nonsense

Adding contacts is a familiar activity to anyone who wants to add a contact

Throwing popups in the face of a new user is just not what we need more of right now

I wish we had real UX people to help us tbh. I'm not qualified for this

It seems to me we're all making stabs in the dark

not all all but ..

moparisthebest, search for "xep poke"

I don't claim to be a UX expert at all. But the effect of adding steps to an onboarding flow is well documented by now

(and it's a negative one)

> I don't care much about the protocol - if people don't like the iq thing, come up with something else I already came up with something else ;)

marc: where?

In the XEP?

The current revision?

The 'regular' way via IBR

Rough consensus and running code!

I see a lot of TODO

True, not saying the XEP is ready just that there is another way how to provide the token

I would need to dig up chat logs to remember the things that drove us to the preauth iq, but not depending on the old IBR was one reason

The "new IBR" is not good enough (currently?) though

What's the new ibr?

I don't see any advantage of 398, if you mean that

389

Whatever ;)

Where is the advantage for 401?

For 401 alone? None afaik

For XMPP? It would be nice to have a more flexible registration flow in general

(I repeat that today's 389 is not that, but it's a step in the right direction)

Yep, but that's off topic for 401 and how to provide the token

Not if the answer is simply "do this preauth thing and register however you want"

I'm afk now, but please let me know if there is a good reason for the IQ approach. I really dislike this approach 😶

^ is why I dislike IBR, weird thing looking like an iq stanza long before that's supposed to be allowed

I agree

I'd love to move away from all iqs before bind

At least in Prosody it's not even treated as a stanza, just a weird "nonza" that happens to be in the "jabber:client" namespace

... not anymore. Used to be an uncomfortable amount of of exceptions in a bunch of places that allowed iq stanzas on unauthenticated connections under certain conditions

So, it would be nice to get 389 moving again.

should I do something special to have firefox render XEP's XML files? it complains about `XML Parsing Error: undefined entity` while chrome displays it without any problem