XSF Discussion - 2018-12-03

ping

pong

pong (DUP!)

reminds me of the hundreds of Receipts in MUC history.

Some clients don't just send Receipts as type=groupchat into a MUC, they also do so on each MUC history sync.

Steve Kille: did we drop the ability to provide channel info / config during channel creation, with the Big Split™?

ralphm: it did

Core (XEP-0369) has a minimal "create channel".

The fancy stuff went into MIX-ADMIN (XEP-0406).

Is there a problem wiith doing two ops?

I don't think so, particularly, as long as we're careful to default to be maximally closed and open things up via config.

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.

necessarily even

Modularity is good

That can't be held as a general truth

And the prose around channel creation says that it “MAY be created with default parameters”, but there is no other way (anymore).

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.

I've made a note to sort edits here to clarify things. Unless people are very keen to see a jumbo op

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.

my preference too

MUC has a hack to make them not distinct steps (locking)

Indeed. I think it's cleaner to avoid the hack.

Agreed. An atomic create+configure is quite sensible in my mind :)

Or, at least, that particular hack - if we were going to do it as a single op, hopefully we'd do better.

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.

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.

(too)

Unfortunately, because we have also split up form namespaces, you'd now have to either pass in two forms, or use Clark's Notation. :-(

There's also a latency aspect to the multiple steps, especially in mobile settings with low-bandwidth/speed networks.

I don't think latency is actually true, there's no more roundtrips, only more stanzas.

Isn't it two RTTs vs one?

Unless you can configure the MIX before receiving the creation response

I assume Kev means you could optimistically pipeline the config

Indeed.

which is not a thing most XMPP libraries will let you do

Really? :o

You have a counterexample? I assume Swiften will, or you wouldn't have suggested it :)

Anyway. create+configure does have advantages if we get the failure rules right.

Swiften will let you send any stanzas you want.

Sure, but can you tell it to send two stanzas "together"?

Oh, you probably didn't mean that

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.

Right

Create+configure does mean you can avoid the client logic of create, configure, catch the configure failure, destroy the room.

Yep

It's so attractive that I've been pondering over a spec for create+configure in MUC

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.

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...

What's the right incantation to receive the last 50 messages from MAM for a given contact JID?

Ge0rG, filter with=contact-jid and in the RSM put an empty <before/> element as in https://xmpp.org/extensions/xep-0059.html#last

and <max>50</max> of course

MattJ: thanks!

MattJ: judging from the number of inquiries, this should be added to 0313

Kev: for ad hoc channels you can't pipeline

Well whose fault is that? Blame the authors :p

So, yeah, create-with-configuration is probably sensible.

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.

Kev: Now the question is, how do we put create-with-configuration back in? Would we indeed pass in two forms?

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).

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.

A short name like xsf@mix.xmpp.org is nicer to communicate than 725c9f1d-c653-4715-988c-764e23cd304c@mix.xmpp.org.

(outside of the protocol itself)

You need external identifiers.

So you need to be able to say "Channel #xsf on server muc.xmpp.org" in one form or another.

Yeah, and if that happens to match the channel JID, that's a nice bonus

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.

Of course References could play a role within XMPP, not so much outside.

Within XMPP you could say #xsf but have the reference point to aoud.rugadr.gucdant.,udn@muc.xmpp.org, yes.

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?

There is https://xmpp.org/rfcs/rfc6120.html#stanzas-error-conditions

No i18n I'm afraid

Ge0rG: it is also likely you don't really want that

ralphm: because I don't want to present understandable error messages to the user?

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.

Like `item-not-found` can mean a world of different things depending on the context.

Right. So what I want is a map of (situation, error, language) -> human readable string

and I'm pretty sure this is interoperable between clients.

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

"XMPPError: not-allowed - cancel" is just not helpful to a normal person.

jonas’: not at all

Ge0rG: "ej tillåten" or "verboten" wouldn't be that much better

VERRBOTEN

Zash: it would be.

not really

at least it would be in the user's language.

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

and you can’t even tell android folks to run the client with LANG=C

jonas’: okay, so I show the translation plus the original XML then :P

But *what* wasn't allowed/found?

cant you just add a text node to the error?

if i recall ejabbered does that for many error stanzas

That makes it someone elses problem

prosody doesn't. But then you need to maintain a map of (situation, error, language) -> human readable string in the server!

Prosody does, sometimes

the server might know better than the client what went wrong though

Zash: hi there, someone else!

although not in all cases

e.g. PEP

where the server doesn’t know what’s going on either

Localization that way is hard. Now the entities taking to you need to know the language

ralphm, no

you can send multiple languages in <error/>

Sometimes there are multiple different causes for the same error (type, condition)

and even if you want to avoid that, you can use the xml:lang on the incoming stanza (which is always present)

...or they need to stuff all languages into the error.

> use the xml:lang on the incoming stanza (which is always present) is it?

Ge0rG, yes

it is required on the <stream:stream/>, and transfers from that to the stanzas on routing

i think for most errors it makes totally sense for the server to add a text

and this works fine

For initial stream headers, the initiating entity SHOULD include the 'xml:lang' attribute.

well, SHOULD

See.

not-authorized can mean many things, only the server can give a more descriptive error text

I'd still not want to present this to an end user

why not?

it makes no sense to display a generic error message (from the client) that can never hit the point whats wrong

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 ...

Because you don't control what the other party is putting in there, and the same issue might yields different messages

if i upload a file via httpupload, there are mutliple confitions that maybe prevent me from uploading but all have the same error

not-authorized

and the client cannot distinguish which of those reasons it is, just by looking at forbidden

it doesnt help the user at all if i show a generic text, NOT AUTHORIZED

ejabbered provides the real error in the text translated

jonas’: this is why there's the ability to have application specific error condition elements

there is no better thing really

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"

ralphm, they’re underused though

ralphm, but point taken

Agreed

ralphm: The logic is, in theory the other party might provide a bad/misleading error message so better not ever show any of them?

Let's just not have errors

Let's always succeed! \o/

Holger: support wise yes

ralphm: Not my experience.

why ralphm support wise this is gold

I think it's sensible to have some way to show the underlying error condition

i can go to the server admin and tell him the exact error message

Most of the time these messages are not actionably by a user

not i got a "not-authorized"

It can be behind a long-press or somesuch

That is a great idea

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.

"Something went wrong [show details]"

the point that this trys to solve is, there are 100 different reasons for a error happening, but only 10 types of errors

Yes.

Holger: Commendable, but I disagree, unless like what Zash described

To some extent, can't you guesstimate the actionability of the error based on the error type?

wait/cancel/auth etc

Zash's suggestion sounds like a compromise between my point and the one I don't get :-)

Zash: Sure, sometimes.

What do the great gods of UX say about this?

How's the error condition received by the remote party is less likely to be incorrect/misleading than a descriptive error text?

Zash: our UX people usually go with "Oops, something went wrong", unless the app has a better explanation.

For a web app and a server-side error that can be done

Holger: because your error message might be something that doesn't make any sense to a user

It's not about making sense to a user but helping support.

And this is where we disagree

The trade-offs may well be different for closed systems where you basically just need a timestamp and then check the server logs.

Well I'm no good at helping users who report "something went wrong" messages but okay.

I think each point in this conversation depends on exactly what kind of error it is

But it's usually an all-or-nothing decision for client developers, I'd assume.

MattJ: error.type = cancel | modify | auth | wait ?

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.

Zash, exactly (if those categories map cleanly)

MattJ: Hopefully they'll map to whether the user should wait or give up or do something

Well "wait" is clear enough that it's a temporary issue that can be fixed by retrying, indeed

The others are more vague

and all this of course depends on entities setting the type correctly :)

"Something went wrong, {wait:try again later; auth:you're not allowed to do that, Dave; cancel: sorry, that won't work."

MattJ: Don't forget that it depends on XEPs not mandating weird error conditions for things

see best example is "wait"

httpupload server mod says you reached your quota

you have to wait one day

this can be in a error text

"A temporary problem" doesnt help the user at all

Yes, agreed

I'm a big fan of <text>, and strongly disagree with the spec when it says it shouldn't be displayed to the user

In the past that may have been sensible, but I try to choose sensible error texts whenever possible

The errors I run into don't have error texts at all.

the best is the forbidden error in combination with MUCs

Gajim just had its own text for that, it always displayed "You are banned from that room"

:D

The not-acceptable one? Yeah, if Prosody doesn't send a <text> with that, it should

It's been on my todo to investigate for a while

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.

Ge0rG: Have you tried sending a presence probe to yourself? ✏

Zash: no

Memberbot is ready for you guys again ;-)

https://old.reddit.com/r/opensource/comments/a2u54g/hey_tumblr_users_here_is_why_movim_could_be_the/