lovetoxwhy is the error in the example type=cancel?
lovetoxwould type=modify not fit much better?
lovetoxit seems really important for IBR
lovetoxbecause if it returns the register form with an error, and type = modify
lovetoxi would not request the form again
lovetoxinstead show the form attached to the error iq
jonas’the form may not be included in the IQ error reply.
lovetoxthen i will not display it
lovetoxand need to request it again
lovetoxbut especially for form errors it is nice to attach the form
GuusEven 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.
lovetoxso we have error and the corresponding form with the values
lovetoxin one single place
lovetoxGuus, i thought examples are not normative, so can be changed any time
GuusNot 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.
lovetoxi 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
Ge0rGWe can't change a Final XEP, can we?
lovetoxbut i dont see how this would cause any problem for an implementation
lovetoxif a implementation follows the RFC
lovetoxcancel -- do not retry (the error cannot be remedied)
lovetoxthis would mean a client would not let a user try again on a username conflict
lovetoxand i guess we can all guess this is very unlikely
lovetoxso every client already ignores the type
Ge0rGlovetox: unless a client is hardcoded to treat type=cancel for retry ;)
lovetoxthen it would not follow the RFC, as it says *do not retry* :D
Ge0rGXEP beats RFC
lovetoxlike never, you had one try to register at this server and you failed
Ge0rG> 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! ;)
ZashDid the '77 author perhaps simply copy https://xmpp.org/rfcs/rfc6120.html#stanzas-error-conditions-conflict
lovetoxif you want to test, there is a switch in advanced config editor to force enable it
marclovetox: i have a wip implementation for 389
marcThe plan is to implement basic registration and enhance it later with token / 401
lovetoxgood to know, i ping you once i have time to work on it
marcyep, my client is implemented with aioxmpp
Steve Killehas joined
Dele Olajidehas left
Dele Olajidehas joined
Dele Olajidehas left
emusWhy is the /me command actually part of the compliance suite?
ZashIt's expected of clients to support it
Ge0rGemus: because it's my favorite command!
ZashBecause you didn't invent a XEP to replace it!!1!1!1eleventyeleven!
emusjust out of interest because I was wondering why this goes to the level of good experience
emus(like group chat)
Dele Olajidehas joined
marc> just out of interest because I was wondering why this goes to the level of good experience
> (like group chat)
Ge0rGIt's about creating a consistent IM experience over different clients.
Ge0rGThat and Consistent Colors were the most contested additions
Ge0rGI'll try to sneak in some more UX this year
Ge0rGmarc: speaking of which, how do we proceed with 0401?
marcGe0rG: as mentioned before, I have a poc for 389 for ejabberd
marcOnce that's done I will continue with 401
marcUnfortunately, the token thing is not that easy with ejabberd
Ge0rGmarc: prosody has implemented the token thing already, even both variants AFAICT.
emusSure, it's not that I dont like it
marcGe0rG: not based on 389 I guess?
Ge0rGmarc: no, because of chicken and eggs
marcYes, I don't like the solo action of prosedy
Ge0rGThe solo action of fixing a long standing problem?
Ge0rGTogether with two (three?) client implementations?
Ge0rGmarc: when we implemented 401, we had the impression that there is no implementation yet of it
marcI don't see lots of new users just because this solo action ;)
Ge0rGMy goal was to make it fly with minimal new protocol, not to reinvent all of IBR
Ge0rGmarc: have you seen the new prosody invitation page?
marcGe0rG, maybe, I don't remeber... I saw something some time ago
Ge0rGmarc: live install on https://xmpp-trial1.ietf.org/
marcGe0rG, nice page :)
marcI don't like to approach and the protocol but the page is nice
marcAlso the blog post
Ge0rGmarc: users don't care about the protocol
marcGe0rG, sure, I'm not a user ;)
MattJMistake #1 :)
Ge0rGmarc: why aren't you using MIX yet, then?
marcMattJ, I'm a user but I care about the protocol
MattJSo do I
marcGe0rG, sorry but I don't want to waste my little time about useless discussions (MIX)
Ge0rGmarc: thanks for the excellent idea of using "I don't care about protocol" as my Council 2021 slogan!
MattJI care about the protocol, I also care about getting things done
MattJWhere is the new XEP-0401, since the previous attempt at fixing it was reverted?
marcMattJ, I sent you a proposal quite some time ago but you never responded
marcNo blaming, just saying
MattJI think I approved it verbally after looking through?
marcNo, you had no time
MattJIn any case, please don't hold off a new revision because of me
MattJI am sure feedback will come if there are still improvements to be made
marcGe0rG, again, no time for trolling sorry
Ge0rGmarc: I'm not trolling
ZashHey if I could say "Bring back 2006-era XMPP" and get on Council, why not that?
Ge0rGmarc: 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
Ge0rGWorking or documented
marcYep, either we have to change it later then or you have to document it properly
MattJThe current implementation is working and documented
marcThen everything is fine?
Ge0rGmarc: like this? https://github.com/xsf/xeps/pull/874
Ge0rGNow I'm trolling
ZashOnly Daniel responded to that thread?
Ge0rGI 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
marcGe0rG, what is your question?
Ge0rG> marc: speaking of which, how do we proceed with 0401?
marcGe0rG, you know my standpoint, no?
MattJAs 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.
Ge0rGmarc: so we are not going to reach agreement?
MattJThe preauth iq was chosen for maximum compatibility with all current and future IBR mechanisms
jonas’MattJ, appeal to council to transfer authorship of the XEP and get it documented?
marcGe0rG, MattJ I don't care what you guys do but I don't like the approach so I won't spend on it
Ge0rGmarc: I'd like to document our approach under the XSF umbrella
marcBut document it if you like
marcGe0rG, sure, I won't block it
marcWhy would I?
Ge0rGmarc: you already did
marcGe0rG, you should take authorship in that case then?
MattJmarc: it matters to me if we don't get an ejabberd implementation
marcMattJ, I'm not an ejabberd maintainer nor regular dev
marcI'm working on 389 - that's it
MattJI care less about documentation, it is already documented on xmpp.org and modernxmpp.org
MattJBut I don't want to see the ecosystem split, or for this to be Prosody-only thing
MattJIt's too important
marcMattJ, me too
marcBut I don't want to spend time on a token-only thing
marcThat's why I'm interested in 389 - that's it
MattJOk, so can we get the rejected revision of 401 republished?
MattJIt is already in attic
MattJI link to it
Ge0rGmarc: 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
Ge0rGIt's been in limbo for over a year now
ZashWanna publish something as an Historical XEP?
marcGe0rG, I don't care about ownership
Ge0rGmarc: do you care about 0401?
marcGe0rG, but maybe it makes sense to make different XEPs for different approaches? I don't know
marcWould be nice to have *one* approach but I don't see this atm
MattJmarc: can you summarize what makes your approach fundamentally different?
marcMattJ, there is no fundamental difference, just based on an extenisble approach (389) which will be implemented sooner or later anyway (my assumption)
Ge0rGVersion 0.0.1 (2018-01-10)
Ge0rGmarc: well, you can't force people to implement 389 by requiring it in a semi related other xep
MattJIt seems easiest to me if we do just submit preauth as a separate XEP
Ge0rGMattJ: a separate XEP based on what?
MattJWhat do you mean?
marcGe0rG, I don't want to force anybody
marcGe0rG, just my feeling that we need something extensible anyway in the future
Ge0rGMattJ: 0401 still contains TODOs
MattJGe0rG: well, we'll have to factor out or duplicate common parts
Ge0rGmarc: nothing wrong to put the working approach into 0401 now and add 389 in that extensible future
MattJE.g. make 0401 only about obtaining URIs/URLs?
MattJAnd define registration flow in other docs
Ge0rGMattJ: fine with me
MattJWe are all in agreement about the adhoc commands in 401, right?
Ge0rGmarc: who should do the splitting?
Ge0rGCan we get 402 and 403? 😁
marcThey're already taken, no?
Ge0rGmarc: are you okay with me or MattJ splitting out the registration parts from 0401 into a new XEP?
Ge0rGmarc: do you want to keep a XEP for the modified IBR that was discouraged by Council, or would you like to aim right for 388?
Ge0rGmarc: 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?
Ge0rGThe part that's currently in §5.5
marcGe0rG, No, I would aim right for 389
Ge0rGmarc: do you have anything written up for 389?
Ge0rGYes, we could aim for two consecutive XEP numbers
marcGe0rG, no, but it's not more than a few lines of text I guess
marcI prefer to have a poc implementation before writing something down
Ge0rGmarc: I'm not sure I want to wait that long
Dele Olajidehas left
MattJI'm off for a bit, thanks for the productive discussion, I think we're getting somewhere :)
marcGe0rG, I'm afk next week, so if you need something from my side let me know this week