XSF Discussion - 2020-10-19

question regarding https://xmpp.org/extensions/xep-0077.html#example-6

Username conflict

why is the error in the example type=cancel?

would type=modify not fit much better?

Probably

Right

it seems really important for IBR

because if it returns the register form with an error, and type = modify

i would not request the form again

instead show the form attached to the error iq

the form may not be included in the IQ error reply.

then i will not display it

and need to request it again

but especially for form errors it is nice to attach the form

Even if the suggested modification makes sense, I wonder if changing that now, given that this was defined 15 years ago, would hurt more than it'd bring benefits.

so we have error and the corresponding form with the values

in one single place

Guus, i thought examples are not normative, so can be changed any time

Not being normative doesn't mean 'that's how people have been doing it' - I'm not sure if that's actually the case, though, but I'd least consider that such a change might introduce issues for existing implementations.

i dont care much about changing it, but i want to write my code so that if some server dev someday cares about a good user experience for ibr, its at least possible

We can't change a Final XEP, can we?

but i dont see how this would cause any problem for an implementation

if a implementation follows the RFC

cancel -- do not retry (the error cannot be remedied)

this would mean a client would not let a user try again on a username conflict

and i guess we can all guess this is very unlikely

so every client already ignores the type

lovetox: unless a client is hardcoded to treat type=cancel for retry ;)

then it would not follow the RFC, as it says *do not retry* :D

XEP beats RFC

like never, you had one try to register at this server and you failed

lovetox: haha

> Note: Once an XMPP Extension Protocol has been advanced to a status of Final, every effort shall be made to limit the scope of modifications; in particular, backwards-incompatible changes shall not be made. However, limited modifications may be made as long as they are optional, backwards-compatible extensions rather than modifications to the core protocol itself. Therefore, a Final protocol is safe for deployment in mission-critical applications. Good luck! ;)

Did the '77 author perhaps simply copy https://xmpp.org/rfcs/rfc6120.html#stanzas-error-conditions-conflict

Says <conflict> SHOULD go with "cancel"

Ge0rG: time for a new XEP

IBR2?

IBR2!

Best Practices for In-Band Registration :p

"Don't"

eta: https://xmpp.org/extensions/xep-0389.html

I like IBR though :c

does a server support 0389?

Does a client support 0389?

answers: no

chicken-egg IBR

i would be willing to implement it, if some server dev also would work on the server side

I might have half an implementation somewhere

However I imagine it predatest the latest updates and will need some changes

Mmmmmm, can haz bookmarks 2 plz?

https://igniterealtime.org:443/httpfileupload/Jax4Cfo6gVIqTNq53VnfecKbZgw/image.png

&lol;

Zash, Gajim has a bookmarks 2 impl

if you want to test, there is a switch in advanced config editor to force enable it

lovetox: i have a wip implementation for 389

for ejabberd

The plan is to implement basic registration and enhance it later with token / 401

good to know, i ping you once i have time to work on it

yep, my client is implemented with aioxmpp

Why is the /me command actually part of the compliance suite?

It's expected of clients to support it

emus: because it's my favorite command!

Because you didn't invent a XEP to replace it!!1!1!1eleventyeleven!

just out of interest because I was wondering why this goes to the level of good experience

(like group chat)

> just out of interest because I was wondering why this goes to the level of good experience > (like group chat) +1 :)

It's about creating a consistent IM experience over different clients.

That and Consistent Colors were the most contested additions

I'll try to sneak in some more UX this year

marc: speaking of which, how do we proceed with 0401?

Ge0rG: as mentioned before, I have a poc for 389 for ejabberd

Once that's done I will continue with 401

Unfortunately, the token thing is not that easy with ejabberd

marc: prosody has implemented the token thing already, even both variants AFAICT.

Sure, it's not that I dont like it

Ge0rG: not based on 389 I guess?

marc: no, because of chicken and eggs

Yes, I don't like the solo action of prosedy

The solo action of fixing a long standing problem?

Together with two (three?) client implementations?

marc: when we implemented 401, we had the impression that there is no implementation yet of it

I don't see lots of new users just because this solo action ;)

My goal was to make it fly with minimal new protocol, not to reinvent all of IBR

marc: have you seen the new prosody invitation page?

Ge0rG, maybe, I don't remeber... I saw something some time ago

link?

https://blog.prosody.im/great-invitations/

marc: live install on https://xmpp-trial1.ietf.org/

Ge0rG, nice page :)

MattJ: ⬆️👍

I don't like to approach and the protocol but the page is nice

Also the blog post

marc: users don't care about the protocol

Ge0rG, sure, I'm not a user ;)

Mistake #1 :)

marc: why aren't you using MIX yet, then?

MattJ, I'm a user but I care about the protocol

So do I

Ge0rG, sorry but I don't want to waste my little time about useless discussions (MIX)

marc: thanks for the excellent idea of using "I don't care about protocol" as my Council 2021 slogan!

I care about the protocol, I also care about getting things done

Where is the new XEP-0401, since the previous attempt at fixing it was reverted?

MattJ, I sent you a proposal quite some time ago but you never responded

No blaming, just saying

I think I approved it verbally after looking through?

No, you had no time

In any case, please don't hold off a new revision because of me

I am sure feedback will come if there are still improvements to be made

Ge0rG, again, no time for trolling sorry

marc: I'm not trolling

Hey if I could say "Bring back 2006-era XMPP" and get on Council, why not that?

marc: I'd love to have a working and documented way to invite people to xmpp. So far I have to choose between those two, and you know how I chose

two?

Working or documented

Yep, either we have to change it later then or you have to document it properly

The current implementation is working and documented

Then everything is fine?

marc: like this? https://github.com/xsf/xeps/pull/874

Now I'm trolling

Only Daniel responded to that thread?

I could also fork 0401 or make a new "Using 0401 with a pre IBR IQ" XEP. But that would require 0401 to be in a stable state

Ge0rG, what is your question?

> marc: speaking of which, how do we proceed with 0401?

Ge0rG, you know my standpoint, no?

As I see it, the XEP was stalled with no implementations and unanswered questions. Out of necessity we figured out a solution, implemented it in 4 clients and 1 server. The update wasn't accepted, and the XEP has not been updated since.

marc: so we are not going to reach agreement?

The preauth iq was chosen for maximum compatibility with all current and future IBR mechanisms

MattJ, appeal to council to transfer authorship of the XEP and get it documented?

Ge0rG, MattJ I don't care what you guys do but I don't like the approach so I won't spend on it

marc: I'd like to document our approach under the XSF umbrella

But document it if you like

Ge0rG, sure, I won't block it

Why would I?

marc: you already did

Ge0rG, you should take authorship in that case then?

marc: it matters to me if we don't get an ejabberd implementation

MattJ, I'm not an ejabberd maintainer nor regular dev

I'm working on 389 - that's it

I care less about documentation, it is already documented on xmpp.org and modernxmpp.org

But I don't want to see the ecosystem split, or for this to be Prosody-only thing

It's too important

MattJ, me too

But I don't want to spend time on a token-only thing

That's why I'm interested in 389 - that's it

Ok, so can we get the rejected revision of 401 republished?

For Attic?

It is already in attic

I link to it

Oh

marc: I don't want to disown you. If you are okay with giving me authorship, well, now we are talking. But I'd rather have a separate document with that pre-ibr iq documented, but that requires that you finish 0401

It's been in limbo for over a year now

Wanna publish something as an Historical XEP?

Ge0rG, I don't care about ownership

marc: do you care about 0401?

Ge0rG, but maybe it makes sense to make different XEPs for different approaches? I don't know

Would be nice to have *one* approach but I don't see this atm

marc: can you summarize what makes your approach fundamentally different?

MattJ, there is no fundamental difference, just based on an extenisble approach (389) which will be implemented sooner or later anyway (my assumption)

Version 0.0.1 (2018-01-10) First submission.

marc: well, you can't force people to implement 389 by requiring it in a semi related other xep

It seems easiest to me if we do just submit preauth as a separate XEP

MattJ: a separate XEP based on what?

What do you mean?

Ge0rG, I don't want to force anybody

Ge0rG, just my feeling that we need something extensible anyway in the future

MattJ: 0401 still contains TODOs

Ge0rG: well, we'll have to factor out or duplicate common parts

marc: nothing wrong to put the working approach into 0401 now and add 389 in that extensible future

E.g. make 0401 only about obtaining URIs/URLs?

And define registration flow in other docs

MattJ: fine with me

sounds good

We are all in agreement about the adhoc commands in 401, right?

marc: who should do the splitting?

MattJ: yes

Great

Yes

Can we get 402 and 403? 😁

They're already taken, no?

Yes

marc: are you okay with me or MattJ splitting out the registration parts from 0401 into a new XEP?

Ge0rG, sure!

Perfect, thanks!

marc: do you want to keep a XEP for the modified IBR that was discouraged by Council, or would you like to aim right for 389? ✏

The part that's currently in §5.5

Ge0rG, No, I would aim right for 389

marc: do you have anything written up for 389?

Ge0rG, spec-wise?

Yes, we could aim for two consecutive XEP numbers

Ge0rG, no, but it's not more than a few lines of text I guess

I prefer to have a poc implementation before writing something down

marc: I'm not sure I want to wait that long

I'm off for a bit, thanks for the productive discussion, I think we're getting somewhere :)

Yep

Ge0rG, I'm afk next week, so if you need something from my side let me know this week

or the week after, of course :)

marc: thanks