reminds me of the hundreds of Receipts in MUC history.
Ge0rG
Some 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
ralphm
Steve 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 Kille
ralphm: it did
Steve Kille
Core (XEP-0369) has a minimal "create channel".
Steve Kille
The fancy stuff went into MIX-ADMIN (XEP-0406).
Steve Kille
Is there a problem wiith doing two ops?
gnauckhas joined
Kev
I 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
ralphm
Steve Kille: not nessarily, but you now have to do three requests to create the channel, set the name, description, and then potentially set ownership.
ralphm
necessarily even
Steve Kille
Modularity is good
MattJ
That can't be held as a general truth
ralphm
And the prose around channel creation says that it “MAY be created with default parameters”, but there is no other way (anymore).
ralphm
It 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 Kille
I've made a note to sort edits here to clarify things. Unless people are very keen to see a jumbo op
Kev
Creation 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 Kille
my preference too
MattJ
MUC has a hack to make them not distinct steps (locking)
Kev
Indeed. I think it's cleaner to avoid the hack.
MattJ
Agreed. An atomic create+configure is quite sensible in my mind :)
Kev
Or, at least, that particular hack - if we were going to do it as a single op, hopefully we'd do better.
Kev
atomic 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.
ralphm
I 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)
ralphm
Unfortunately, because we have also split up form namespaces, you'd now have to either pass in two forms, or use Clark's Notation. :-(
ralphm
There'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
Kev
I don't think latency is actually true, there's no more roundtrips, only more stanzas.
Ge0rG
Isn't it two RTTs vs one?
danielhas left
danielhas joined
Ge0rG
Unless you can configure the MIX before receiving the creation response
MattJ
I assume Kev means you could optimistically pipeline the config
Kev
Indeed.
rainslidehas left
MattJ
which is not a thing most XMPP libraries will let you do
Kev
Really? :o
MattJ
You have a counterexample? I assume Swiften will, or you wouldn't have suggested it :)
Kev
Anyway. create+configure does have advantages if we get the failure rules right.
Kev
Swiften will let you send any stanzas you want.
Zashhas left
MattJ
Sure, but can you tell it to send two stanzas "together"?
MattJ
Oh, you probably didn't mean that
Zashhas left
Zashhas left
Kev
Together? 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.
MattJ
Right
vaulorhas left
vanitasvitaehas left
Kev
Create+configure does mean you can avoid the client logic of create, configure, catch the configure failure, destroy the room.
MattJ
Yep
MattJ
It's so attractive that I've been pondering over a spec for create+configure in MUC
Kev
Well, 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.
Ge0rG
I'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
Ge0rG
What'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
MattJ
Ge0rG, filter with=contact-jid and in the RSM put an empty <before/> element as in https://xmpp.org/extensions/xep-0059.html#last
MattJ
and <max>50</max> of course
404.cityhas joined
Ge0rG
MattJ: thanks!
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
rionhas left
lnjhas joined
mimi89999has left
mimi89999has joined
Ge0rG
MattJ: 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
ralphm
Kev: for ad hoc channels you can't pipeline
Kev
Well whose fault is that? Blame the authors :p
Kev
So, yeah, create-with-configuration is probably sensible.
blablahas joined
lhas joined
ralphm
Looking 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.
ralphm
Kev: Now the question is, how do we put create-with-configuration back in? Would we indeed pass in two forms?
Yagizahas joined
Kev
I 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
ralphm
I 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.
ralphm
A 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)
Kev
You need external identifiers.
Kev
So you need to be able to say "Channel #xsf on server muc.xmpp.org" in one form or another.
ralphm
Yeah, and if that happens to match the channel JID, that's a nice bonus
ralphm
Problem 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.
ralphm
Of course References could play a role within XMPP, not so much outside.
Kev
Within 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
Ge0rG
is 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?
Zash
There is https://xmpp.org/rfcs/rfc6120.html#stanzas-error-conditions
Zash
No i18n I'm afraid
ralphm
Ge0rG: it is also likely you don't really want that
Ge0rG
ralphm: because I don't want to present understandable error messages to the user?
ralphm
No, 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.
ralphm
Like `item-not-found` can mean a world of different things depending on the context.
blablahas left
blablahas joined
Ge0rG
Right. So what I want is a map of (situation, error, language) -> human readable string
Ge0rG
and 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.
ralphm
jonas’: not at all
Zash
Ge0rG: "ej tillåten" or "verboten" wouldn't be that much better
waqashas joined
jonas’
VERRBOTEN
Ge0rG
Zash: it would be.
jonas’
not really
Ge0rG
at 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
Ge0rG
jonas’: okay, so I show the translation plus the original XML then :P
Zash
But *what* wasn't allowed/found?
lovetox
cant you just add a text node to the error?
lovetox
if i recall ejabbered does that for many error stanzas
Zash
That makes it someone elses problem
Ge0rG
prosody doesn't. But then you need to maintain a map of (situation, error, language) -> human readable string in the server!
Zash
Prosody does, sometimes
rionhas left
jonas’
the server might know better than the client what went wrong though
Ge0rG
Zash: 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
ralphm
Localization 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/>
Zash
Sometimes 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
lovetox
i think for most errors it makes totally sense for the server to add a text
lovetox
and this works fine
jonas’
For initial stream headers, the initiating entity SHOULD include the
'xml:lang' attribute.
jonas’
well, SHOULD
Ge0rG
See.
lovetox
not-authorized can mean many things, only the server can give a more descriptive error text
ralphm
I'd still not want to present this to an end user
lovetox
why not?
lovetox
it 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
...
ralphm
Because you don't control what the other party is putting in there, and the same issue might yields different messages
lovetox
if i upload a file via httpupload, there are mutliple confitions that maybe prevent me from uploading but all have the same error
lovetox
not-authorized
jonas’
and the client cannot distinguish which of those reasons it is, just by looking at forbidden
lovetox
it doesnt help the user at all if i show a generic text, NOT AUTHORIZED
lovetox
ejabbered provides the real error in the text translated
ralphm
jonas’: this is why there's the ability to have application specific error condition elements
lovetox
there 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
ralphm
Agreed
Holger
ralphm: The logic is, in theory the other party might provide a bad/misleading error message so better not ever show any of them?
Zash
Let's just not have errors
Zash
Let's always succeed! \o/
ralphm
Holger: support wise yes
Holger
ralphm: Not my experience.
lovetox
why ralphm support wise this is gold
Zash
I think it's sensible to have some way to show the underlying error condition
lovetox
i can go to the server admin and tell him the exact error message
ralphm
Most of the time these messages are not actionably by a user
lovetox
not i got a "not-authorized"
Zash
It can be behind a long-press or somesuch
ralphm
That is a great idea
Holger
ralphm: 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]"
lovetox
the point that this trys to solve is, there are 100 different reasons for a error happening, but only 10 types of errors
Holger
Yes.
ralphm
Holger: Commendable, but I disagree, unless like what Zash described
Zash
To some extent, can't you guesstimate the actionability of the error based on the error type?
Zash
wait/cancel/auth etc
Holger
Zash's suggestion sounds like a compromise between my point and the one I don't get :-)
Holger
Zash: Sure, sometimes.
Zash
What do the great gods of UX say about this?
Nekithas left
Nekithas joined
Holger
How's the error condition received by the remote party is less likely to be incorrect/misleading than a descriptive error text?
ralphm
Zash: our UX people usually go with "Oops, something went wrong", unless the app has a better explanation.
Steve Killehas left
Steve Killehas left
MattJ
For a web app and a server-side error that can be done
ralphm
Holger: because your error message might be something that doesn't make any sense to a user
Holger
It's not about making sense to a user but helping support.
ralphm
And this is where we disagree
Holger
The trade-offs may well be different for closed systems where you basically just need a timestamp and then check the server logs.
Holger
Well I'm no good at helping users who report "something went wrong" messages but okay.
MattJ
I think each point in this conversation depends on exactly what kind of error it is
Nekithas left
Nekithas joined
Holger
But it's usually an all-or-nothing decision for client developers, I'd assume.
Either 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
MattJ
Zash, exactly (if those categories map cleanly)
doshas left
Zash
MattJ: Hopefully they'll map to whether the user should wait or give up or do something
MattJ
Well "wait" is clear enough that it's a temporary issue that can be fixed by retrying, indeed
MattJ
The others are more vague
MattJ
and 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."
Zash
MattJ: Don't forget that it depends on XEPs not mandating weird error conditions for things
Steve Killehas joined
lovetox
see best example is "wait"
lovetox
httpupload server mod says you reached your quota
lovetox
you have to wait one day
lovetox
this can be in a error text
Andrew Nenakhovhas joined
lovetox
"A temporary problem" doesnt help the user at all
MattJ
Yes, agreed
MattJ
I'm a big fan of <text>, and strongly disagree with the spec when it says it shouldn't be displayed to the user
MattJ
In the past that may have been sensible, but I try to choose sensible error texts whenever possible
Ge0rG
The errors I run into don't have error texts at all.
lovetox
the best is the forbidden error in combination with MUCs
lovetox
Gajim just had its own text for that, it always displayed "You are banned from that room"
lovetox
:D
MattJ
The not-acceptable one? Yeah, if Prosody doesn't send a <text> with that, it should
MattJ
It's been on my todo to investigate for a while
vaulorhas left
Yagizahas left
Ge0rG
Also no text when you send a message to a MUC you are not in, or when you try to add yourself to your roster.
Zash
Ge0rG: Have you tried sending a presence probe to yourself;✎
Zash
Ge0rG: Have you tried sending a presence probe to yourself? ✏