Ge0rGreminds me of the hundreds of Receipts in MUC history.
Ge0rGSome clients don't just send Receipts as type=groupchat into a MUC, they also do so on each MUC history sync.
Str4tocasterhas left
Str4tocasterhas joined
Str4tocasterhas left
Str4tocasterhas joined
Str4tocasterhas left
Str4tocasterhas joined
tuxhas joined
Str4tocasterhas left
krauqhas left
Str4tocasterhas joined
krauqhas joined
Str4tocasterhas left
Str4tocasterhas joined
Str4tocasterhas left
Str4tocasterhas joined
Str4tocasterhas left
Str4tocasterhas joined
Str4tocasterhas left
Str4tocasterhas joined
Str4tocasterhas left
Str4tocasterhas joined
Str4tocasterhas left
Str4tocasterhas joined
Str4tocasterhas left
Str4tocasterhas joined
Str4tocasterhas left
Str4tocasterhas joined
Str4tocasterhas left
Str4tocasterhas joined
Str4tocasterhas left
Str4tocasterhas joined
Zashhas left
Str4tocasterhas left
Str4tocasterhas joined
Str4tocasterhas left
Str4tocasterhas joined
Str4tocasterhas left
Str4tocasterhas joined
moparisthebesthas joined
moparisthebesthas joined
Str4tocasterhas left
Str4tocasterhas joined
Str4tocasterhas left
pep.has joined
labdsfhas left
labdsfhas joined
vaulorhas left
vaulorhas joined
frainzhas left
vinx55has joined
Sevehas left
frainzhas left
lumihas joined
frainzhas left
Alexhas joined
andyhas left
frainzhas left
frainzhas left
vinx55has left
frainzhas left
Holgerhas left
frainzhas left
vinx55has joined
frainzhas left
vinx55has left
frainzhas left
Zashhas left
mimi89999has left
blablahas joined
Sevehas joined
frainzhas left
blablahas joined
frainzhas left
Guushas left
genofirehas left
genofirehas left
frainzhas left
andyhas joined
mimi89999has joined
Guushas left
Guushas joined
danielhas left
Sevehas joined
vanitasvitaehas left
vanitasvitaehas joined
frainzhas left
moparisthebesthas joined
Guushas left
moparisthebesthas joined
Marc Laportehas joined
blablahas joined
frainzhas left
frainzhas left
vanitasvitaehas left
vanitasvitaehas joined
vanitasvitaehas left
vanitasvitaehas joined
winfriedhas joined
winfriedhas joined
jjrhhas left
blablahas joined
genofirehas left
frainzhas left
Zashhas left
genofirehas left
genofirehas left
frainzhas left
marchas left
marchas joined
ralphmSteve Kille: did we drop the ability to provide channel info / config during channel creation, with the Big Split™?
Marc Laportehas left
frainzhas left
Zashhas left
moparisthebesthas left
blablahas joined
Zashhas left
frainzhas left
frainzhas left
Zashhas joined
Steve Killeralphm: it did
Steve KilleCore (XEP-0369) has a minimal "create channel".
Steve KilleThe fancy stuff went into MIX-ADMIN (XEP-0406).
Steve KilleIs there a problem wiith doing two ops?
gnauckhas joined
KevI don't think so, particularly, as long as we're careful to default to be maximally closed and open things up via config.
APachhas left
rainslidehas joined
frainzhas left
APachhas joined
frainzhas left
rainslidehas left
ralphmSteve Kille: not nessarily, but you now have to do three requests to create the channel, set the name, description, and then potentially set ownership.
ralphmnecessarily even
Steve KilleModularity is good
MattJThat can't be held as a general truth
ralphmAnd the prose around channel creation says that it “MAY be created with default parameters”, but there is no other way (anymore).
ralphmIt would be good to explain how to do this by mentioning the info and config topics there (in MIX-CORE), and pointing to the MIX-ADMIN for changing them.
Steve KilleI've made a note to sort edits here to clarify things. Unless people are very keen to see a jumbo op
KevCreation and configuration being distinct steps seems to make sense to me. You have to support them as distinct steps, so only doing so seems simpler.
Steve Killemy preference too
MattJMUC has a hack to make them not distinct steps (locking)
KevIndeed. I think it's cleaner to avoid the hack.
MattJAgreed. An atomic create+configure is quite sensible in my mind :)
KevOr, at least, that particular hack - if we were going to do it as a single op, hopefully we'd do better.
Kevatomic create-and-configure is ok if you have to have create-and-configure. It's not clear to me that we need it for MIX, if we default to closed, hidden channels.
ralphmI agree that create+configure makes a lot of sense to. Makes creating a channel less complex for clients (no need to keep state during the creation), and allows for rejecting the creation based on certain configuration or info.
ralphm(too)
ralphmUnfortunately, because we have also split up form namespaces, you'd now have to either pass in two forms, or use Clark's Notation. :-(
ralphmThere's also a latency aspect to the multiple steps, especially in mobile settings with low-bandwidth/speed networks.
Guushas left
Tobiashas left
Andrew Nenakhovhas joined
frainzhas left
Tobiashas joined
efrithas joined
alexdehas joined
alexdehas left
alexdehas joined
Zashhas left
gnauckhas left
marchas left
marchas joined
rainslidehas joined
gnauckhas joined
frainzhas left
Alexhas left
gnauckhas left
KevI don't think latency is actually true, there's no more roundtrips, only more stanzas.
Ge0rGIsn't it two RTTs vs one?
danielhas left
danielhas joined
Ge0rGUnless you can configure the MIX before receiving the creation response
MattJI assume Kev means you could optimistically pipeline the config
KevIndeed.
rainslidehas left
MattJwhich is not a thing most XMPP libraries will let you do
KevReally? :o
MattJYou have a counterexample? I assume Swiften will, or you wouldn't have suggested it :)
KevAnyway. create+configure does have advantages if we get the failure rules right.
KevSwiften will let you send any stanzas you want.
Zashhas left
MattJSure, but can you tell it to send two stanzas "together"?
MattJOh, you probably didn't mean that
Zashhas left
Zashhas left
KevTogether? No, but you can issue the send in the same call, which means they've got every chance of going out in the same write if they fit, and certainly aren't roundtripped.
MattJRight
vaulorhas left
vanitasvitaehas left
KevCreate+configure does mean you can avoid the client logic of create, configure, catch the configure failure, destroy the room.
MattJYep
MattJIt's so attractive that I've been pondering over a spec for create+configure in MUC
KevWell, things are a bit worse with MUC to start with. I think if we get the closed-by-default right for MIX, it's /less/ necessary.
Ge0rGI've understood the intent, but don't you need the room JID from the create response as a parameter in the configure request? I'm a bit rusty on the MIX protocol details...
andyhas left
lumihas joined
Andrew Nenakhovhas joined
Ge0rGWhat's the right incantation to receive the last 50 messages from MAM for a given contact JID?
Zashhas left
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
lhas joined
lhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
blablahas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
SamWhitedhas left
SamWhitedhas left
krauqhas joined
igoosehas joined
lhas joined
lhas joined
MattJGe0rG, filter with=contact-jid and in the RSM put an empty <before/> element as in https://xmpp.org/extensions/xep-0059.html#last
MattJand <max>50</max> of course
404.cityhas joined
Ge0rGMattJ: thanks!
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
rionhas left
lnjhas joined
mimi89999has left
mimi89999has joined
Ge0rGMattJ: judging from the number of inquiries, this should be added to 0313
frainzhas left
blablahas joined
rainslidehas joined
marchas left
marchas joined
efrithas left
Yagizahas left
rainslidehas left
ralphmKev: for ad hoc channels you can't pipeline
KevWell whose fault is that? Blame the authors :p
KevSo, yeah, create-with-configuration is probably sensible.
blablahas joined
lhas joined
ralphmLooking at the use cases I have, I would only have ad hoc channels. If you look at e.g. Whatsapp, you'd never know the equivalent of the localpart of the channel JID. For Slack, the channel name (#general) can change over time, so there too, the localpart of the JID would not be something you expose to users. It would probably go in the 'Name' info field.
ralphmKev: Now the question is, how do we put create-with-configuration back in? Would we indeed pass in two forms?
Yagizahas joined
KevI think that's a question I don't have cycles for in the next few minutes, I'm afraid.
The addressing/external identifier thing is interesting. We could in principle work entirely with addressing being distinct, and need a lookup, but then that's compexity and no-one likes complexity (until it's a feature they need).
jjrhhas left
ralphmI can imagine that for more traditional cases you'd still want named (non-ad hoc) channels, but I'm not sure. It is mostly a vanity address.
ralphmA short name like xsf@mix.xmpp.org is nicer to communicate than 725c9f1d-c653-4715-988c-764e23cd304c@mix.xmpp.org.
ralphm(outside of the protocol itself)
KevYou need external identifiers.
KevSo you need to be able to say "Channel #xsf on server muc.xmpp.org" in one form or another.
ralphmYeah, and if that happens to match the channel JID, that's a nice bonus
ralphmProblem is one generally doesn't expect JIDs to change and the systems where you possibly can rename channels (like Slack) are mostly closed ecosystems where you don't have to expose the address.
ralphmOf course References could play a role within XMPP, not so much outside.
KevWithin XMPP you could say #xsf but have the reference point to aoud.rugadr.gucdant.,udn@muc.xmpp.org, yes.
jjrhhas left
blablahas joined
vaulorhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
ThibGhas left
ThibGhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
jonas’has left
Ge0rGis there a central mapping of XMPP errors to human-readable strings? Properly i18nized? With context for the different places where an XMPP error can happen?
ZashThere is https://xmpp.org/rfcs/rfc6120.html#stanzas-error-conditions
ZashNo i18n I'm afraid
ralphmGe0rG: it is also likely you don't really want that
Ge0rGralphm: because I don't want to present understandable error messages to the user?
ralphmNo, because you generally want your app to understand the error in context and then present something meaningful to a user, if needed. This is almost never want is (mapped from) the error condition itself.
ralphmLike `item-not-found` can mean a world of different things depending on the context.
blablahas left
blablahas joined
Ge0rGRight. So what I want is a map of (situation, error, language) -> human readable string
Ge0rGand I'm pretty sure this is interoperable between clients.
jonas’yupp, and when you end up in a situation where there is no such mapping entry, you want to show the unlocalized, original error condition so that at least nerds can debug it
Ge0rG"XMPPError: not-allowed - cancel" is just not helpful to a normal person.
ralphmjonas’: not at all
ZashGe0rG: "ej tillåten" or "verboten" wouldn't be that much better
waqashas joined
jonas’VERRBOTEN
Ge0rGZash: it would be.
jonas’not really
Ge0rGat least it would be in the user's language.
jonas’and then the user comes into the support room of their client and asks what it means and nobody knows what "ej tillåten" means
jonas’and you can’t even tell android folks to run the client with LANG=C
frainzhas left
Ge0rGjonas’: okay, so I show the translation plus the original XML then :P
ZashBut *what* wasn't allowed/found?
lovetoxcant you just add a text node to the error?
lovetoxif i recall ejabbered does that for many error stanzas
ZashThat makes it someone elses problem
Ge0rGprosody doesn't. But then you need to maintain a map of (situation, error, language) -> human readable string in the server!
ZashProsody does, sometimes
rionhas left
jonas’the server might know better than the client what went wrong though
Ge0rGZash: hi there, someone else!
jonas’although not in all cases
jonas’e.g. PEP
jonas’where the server doesn’t know what’s going on either
ralphmLocalization that way is hard. Now the entities taking to you need to know the language
jonas’ralphm, no
jonas’you can send multiple languages in <error/>
ZashSometimes there are multiple different causes for the same error (type, condition)
jonas’and even if you want to avoid that, you can use the xml:lang on the incoming stanza (which is always present)
Ge0rG...or they need to stuff all languages into the error.
Ge0rG> use the xml:lang on the incoming stanza (which is always present)
is it?
jonas’Ge0rG, yes
jonas’it is required on the <stream:stream/>, and transfers from that to the stanzas on routing
lovetoxi think for most errors it makes totally sense for the server to add a text
lovetoxand this works fine
jonas’ For initial stream headers, the initiating entity SHOULD include the
'xml:lang' attribute.
jonas’well, SHOULD
Ge0rGSee.
lovetoxnot-authorized can mean many things, only the server can give a more descriptive error text
ralphmI'd still not want to present this to an end user
lovetoxwhy not?
lovetoxit makes no sense to display a generic error message (from the client) that can never hit the point whats wrong
jonas’ralphm, in the case of a forbidden MUC join for example, there can be many reasons:
- Only members are allowed in this room (and you are not one)
- Only folks from this server are allowed in this room
- You need a password to enter this room
...
ralphmBecause you don't control what the other party is putting in there, and the same issue might yields different messages
lovetoxif i upload a file via httpupload, there are mutliple confitions that maybe prevent me from uploading but all have the same error
lovetoxnot-authorized
jonas’and the client cannot distinguish which of those reasons it is, just by looking at forbidden
lovetoxit doesnt help the user at all if i show a generic text, NOT AUTHORIZED
lovetoxejabbered provides the real error in the text translated
ralphmjonas’: this is why there's the ability to have application specific error condition elements
lovetoxthere is no better thing really
jonas’and thus it’s good if the server supplies this. and the client can show this in addition to its own explanation: "Failed to join group chat. $servermessage"
jonas’ralphm, they’re underused though
jonas’ralphm, but point taken
ralphmAgreed
Holgerralphm: The logic is, in theory the other party might provide a bad/misleading error message so better not ever show any of them?
ZashLet's just not have errors
ZashLet's always succeed! \o/
ralphmHolger: support wise yes
Holgerralphm: Not my experience.
lovetoxwhy ralphm support wise this is gold
ZashI think it's sensible to have some way to show the underlying error condition
lovetoxi can go to the server admin and tell him the exact error message
ralphmMost of the time these messages are not actionably by a user
lovetoxnot i got a "not-authorized"
ZashIt can be behind a long-press or somesuch
ralphmThat is a great idea
Holgerralphm: We added tons of descriptive error messages to ejabberd over the past few months and that helps a *lot* support-wise in practice. If the clients don't hide them.
Zash"Something went wrong [show details]"
lovetoxthe point that this trys to solve is, there are 100 different reasons for a error happening, but only 10 types of errors
HolgerYes.
ralphmHolger: Commendable, but I disagree, unless like what Zash described
ZashTo some extent, can't you guesstimate the actionability of the error based on the error type?
Zashwait/cancel/auth etc
HolgerZash's suggestion sounds like a compromise between my point and the one I don't get :-)
HolgerZash: Sure, sometimes.
ZashWhat do the great gods of UX say about this?
Nekithas left
Nekithas joined
HolgerHow's the error condition received by the remote party is less likely to be incorrect/misleading than a descriptive error text?
ralphmZash: our UX people usually go with "Oops, something went wrong", unless the app has a better explanation.
Steve Killehas left
Steve Killehas left
MattJFor a web app and a server-side error that can be done
ralphmHolger: because your error message might be something that doesn't make any sense to a user
HolgerIt's not about making sense to a user but helping support.
ralphmAnd this is where we disagree
HolgerThe trade-offs may well be different for closed systems where you basically just need a timestamp and then check the server logs.
HolgerWell I'm no good at helping users who report "something went wrong" messages but okay.
MattJI think each point in this conversation depends on exactly what kind of error it is
Nekithas left
Nekithas joined
HolgerBut it's usually an all-or-nothing decision for client developers, I'd assume.
MattJEither it's actionable by the user, by the service admin, by the client developer, or possibly even the server developer. Otherwise a temporary technical problem.
doshas left
MattJZash, exactly (if those categories map cleanly)
doshas left
ZashMattJ: Hopefully they'll map to whether the user should wait or give up or do something
MattJWell "wait" is clear enough that it's a temporary issue that can be fixed by retrying, indeed
MattJThe others are more vague
MattJand all this of course depends on entities setting the type correctly :)
Zash"Something went wrong, {wait:try again later; auth:you're not allowed to do that, Dave; cancel: sorry, that won't work."
ZashMattJ: Don't forget that it depends on XEPs not mandating weird error conditions for things
Steve Killehas joined
lovetoxsee best example is "wait"
lovetoxhttpupload server mod says you reached your quota
lovetoxyou have to wait one day
lovetoxthis can be in a error text
Andrew Nenakhovhas joined
lovetox"A temporary problem" doesnt help the user at all
MattJYes, agreed
MattJI'm a big fan of <text>, and strongly disagree with the spec when it says it shouldn't be displayed to the user
MattJIn the past that may have been sensible, but I try to choose sensible error texts whenever possible
Ge0rGThe errors I run into don't have error texts at all.
lovetoxthe best is the forbidden error in combination with MUCs
lovetoxGajim just had its own text for that, it always displayed "You are banned from that room"
lovetox:D
MattJThe not-acceptable one? Yeah, if Prosody doesn't send a <text> with that, it should
MattJIt's been on my todo to investigate for a while
vaulorhas left
Yagizahas left
Ge0rGAlso no text when you send a message to a MUC you are not in, or when you try to add yourself to your roster.
ZashGe0rG: Have you tried sending a presence probe to yourself;
ZashGe0rG: Have you tried sending a presence probe to yourself?