Modern XMPP project discussion - 2021-09-01

MattJ and/or Zash: The account migration portal (https://migrate.modernxmpp.org/) doesn't seem to work. I get blank page after entering credentials.

Do you have Javascript enabled?

I do.

Ah in different browser, I see "XEP-0156 lookup failed." for one account and blank page for another.

Interesting, which browser(s)?

First IceCat, then Surf.

Regarding terminology (https://docs.modernxmpp.org/terminology/), what is recommended name for subdomain for xmpp server? like im.tld.or or chat.tld.org or ...

In what context? That doesn't seem like the kind of thing you'd mention to the user, so the actual technical term should suffice.

Put another way, I wouldn't talk about domains, I'd talk about "services" such as "chat rooms" or "file upload" or whatever instead.

The user might access admin panel.

Then they're an advanced user and just calling them domains should be fine I'd think

I see.

the recommendation would be "none"

https://snikket.org/service/quickstart/

In that example, chat.example.com is used.

jonas’: Did you mean like example.com apexdomain?

Is there a best practice for delivering input validation errors to clients during in-band registration? It looks like I have 2 options, return an error stanza of <not-acceptable/> with a <text> description of the problem, or use a Data Form and put the error in the <field>'s description. Is there a preference with this sort of thing or another way of doing it? Are Data Forms well supported by clients?

the last question: definitely no

error + text is the most sensible way to go, if you want to be nice you also return the data which was submitted (that is legal: an IQ error can contain the original request)

That's on my list of annoying things to remove from XMPP 2.0 :)

It encourages clients to not track stanzas properly

errors don't always mirror the id anyways and don't always get returned or have a success response so you can't really track anything but iqs in a reasonable way anyways

Can you give any case where errors don't mirror the id? Because that would be a bug. We had this discussion not long ago :)

Did we? I don't recall the details, but I think it was ejabberd that never did or something

Doesn't matter, even if that part is wrong you can't reasonably track errors because there's not always a success case so you just have to guess at timeouts

There's always a success case for iq, it's true that in many cases silence on success is the default (e.g. sending a message)

Yes, excepting IQs as I said before.

So you show success on a message payload then 30s later the error is returned. Oops.

or you do nothing, stop tracking, then the error is returned more likely.

For messages you probably have a local message database where you could look it up by id when you get an error, so not sure why you would have a timeout like that.

fair, I guess if I assume that I can store all message IDs for the duration of the session that's fine. I doubt that's always true though.

XEP-0198 would also tell you whether the message at least reached your local server, which would allow marking anything acked as success

And receipts if you need end-to-end confirmation.

For a simple chat client it may be.

Well the protocol just matches the UI expectations here. You don't indicate success when you send a message, but you may indicate that it was received by your server (198) or by the recipient (184).

A delayed error is common to many protocols

> It encourages clients to not track stanzas properly

MattJ: What about servers?

Servers are always correct

Servers receive errors and might do useful things with them.

And might not have the original stanza in MAM or whatever.

`log("debug", "Recevied an error, but whatever, who cares, discarding it");`

What's the advantage in omitting the original stanza?

Smaller stanzas

Omitting IDs would make them even smaller.

Okay, but if you omit the ID you can't do any sensible tracking

If you omit the original payload, you can

If you omit both, you obviously can't

Force servers to track stanzas just for error handling sounds wrong to me. I think it also sounds wrong to me to force clients.

I really don't understand this perspective at all

Holger, is there any use case where it helps a requesting entity to get the original request delivered with the error response?

I haven't seen one yet.

for IQs anyway

for messages I'm not sure, for presence I'm most certain it makes no sense.

Yes I ran into that more than once.

-v then please :)

Sigh as if I _remember_ stuff.

your git commit log might

MUC service generates e kind of notifications for offline members. On receiving an `error` for a `groupchat` message, it has to decide whether that should trigger a notification. This decision might depend on the payload.

*some kind of

Dunno about IQs specifically. I find the perspective weird to omit potentially useful information if in doubt, rather than vice-versa.

You can encode "should this error trigger a notification" into a single bit in the id

Yeah, if the notification doesn't include the payload.

MattJ, not for type="groupchat" unless you are nasty. the IDs are under control of the original sender.

… at least for the reflection. please don't rewrite MUC IDs randomly, mkay

I assumed some OOB notification was being discussed

I send out a regular groupchat message, and an error for that should possibly trigger an OOB notification.

Whatever, I don't quite see the relevance of random example use cases of mine, anyway.

Regardless of whether they're valid, you'll have a hard time convincing me the original stanza is useless in principle, for all future use cases.

So I'd be careful with making such an assertion, as that's hard to revert.

I mean you can't rely on the thing being in there anyway :)

it is OPTIONAL, which means MAY, which means… nothing

Yes but we could add it to the list of things to add to XMPP 2.0.

Rather than doing the opposite.

fair

though as a client dev, I am not particularly fond of having to carry the original XML around

my parsing discards approximately all things it doesn't know about, so restoring the original XML (even just semantically instead of syntactially) is pretty much impossible in the general (and especially in error) case.

working with a DOM instead would allow that, but it's also grossly inefficient

Whenever I come up with implementation problems I'm told "that's just your implementation problem" :-)

yah, the original xml thing never seemed useful to me either. Leaving unused things in with the justification "I dunno, might be useful to someone at some point" also seems like a bad thing to do.

Holger, I mean, I am happy with making my parsing stricter so that the original XML can be reconstructed... but last time I did that, I had to revert it to talk to ejabberd ;P

Due to an ejabberd bug?

due to code attributes on error elements

which is not technically a bug

I'm just being a bit snarky here

:)

if we're aiming for the possibility of (energy and memory) efficient XMPP client implementations, I think it's hard to argue in favour of having to keep the original XML somewhere until it is clear that no error response will be sent.

Ah, the RFC392?/XEP-0086 thing?

yes, probably

Funny, there was a PR to remove support for that just yesterday :-)

it was mentioned somewhere a few days ago I think

Ot also seems perfectly reasonable to parse the xml, save what you want in database schema/language type system/other serialization and throw the rest away. Always requiring that you also keep the original seems like it just can't work.

Isn't it needed by ... something? MUC probably?

Sam: Only until you decided to accept the stanza, of course.

Zash: The error codes?

`<error code=xxx>` was used by some XEP IIRC

Dunno. MUC has the status codes of course ...

With some luck I'm just confusing it with those status codes

I don't even know if my xml parser would reasonably let me get that info. I could save tokens and re-encode them if necessary I guess. Hope we never sign the original payload or I'd be screwed though.

I'm sure everything will fall apart once we merge that PR ...

kk I understood I'm lost with my desire to receive the original stanza back with errors. Error handling has never been the #1 focus of XMPP :-P

YOLOMPP

Holger: why do you actually want it? I've never seen it used anywhere?

Sam: I mentioned one of my use cases above.

xeps$ ack '<error\ code=' run and be amazed^Wterrified

(I actually implemented that one for a customer who was okay-ish with "won't work for Prosody users".)

I don't see it? What am I missing?

Sam: MUC service generates some kind of notifications for offline members. On receiving an `error` for a `groupchat` message, it has to decide whether that should trigger a notification. This decision might depend on the payload.

"for" how?

Hm?

ahh, yes I see. That makes sense to me at first blush, thanks

"Someone went offline" notifications? Notifications sent to offline members? Something else?

the middle case

out-of-band notifications

Ah, yes.

using type="error" to detect the offlineness

instead of kicking

Holger, I find that use case compelling, but IMO it needs a different way than forcing entities to keep the entire deserialized state of stanzas around until they have been processed successfully, really

What jonas’ said.

Like, if the error has a `<body>` then send send something else?

The server _could_ obviously track all stanzas; or hard-depend on MAM or something.

`<history/>` cache!

tracking all stanzas is about as insane as entities having to keep the XML around :)

not sure how MAM would help in this situation either

oh, you could look up the stanza by ID, gotcha

Well I could try to look up the ID.

if your MAM is indexed on message/@id and not on message/stanza-id/@id

Can you distinguish between an error for a type=groupchat vs type=chat ?

no

s/not on/not just on/

This always seemed like an awkward thing, having a type=error and no way to determine what the original type is. Even if you have the rest of the payload.

indeed. it doesn't matter for IQ much, but for the others it does (presence type="subscribe" errors vs. type="unavailable" errors…)

*nods* let's just fix that part too while we're at it.

are we even at it?

xmpp 2.0? didn't you just commit to writing that and fixing all the problems? I think that's what I heard.

Yup.

Stuff the whole original stanza in a forwarded-envelope? That'd also preserve say, cryptographic signatures that happened to cover id, to, from

I'm busy with RIIRing prosody, sorry ;P

Zash, making things worse? :(

See, Holger heard you too. No backing out now!

Wasn't that the point, people want worse things?

I don't think so :)

I'm totally fine as long as whatever we come up with is super-complicated.

Every stanza to include an XSLT that is used to generate the error reply, check.

transpiled to some Lisp dialect because carrying XSLT directly over the wire may be unsafe

Sounds good. Next customer, please.

Didn't we have xslt already in pubsub

it's been a few times i hear about "xmpp 2.0" and i've read the "office hours" page: https://wiki.xmpp.org/web/XMPP_Office_Hours/2021-04-13-Notes

there's some interesting reflections in there, is that a real project/working-group? are some people gathering feedback on this topic?

or is it just codename for every feature someone wants nowadays? :P

There is no serious active effort right now

At some point there may well be a new round of the core XMPP RFCs, the persons/people working on that will be responsible for gathering such issues, so it helps to have them written down for sure

could we maybe start a public survey of painpoints and ideas across implementations? (a bit like what i've barely started for XMPP spaces)

something like that wiki page, but open to more contributions, and a bit more structured?

Anyone can do anything :)

Do it yourself(tm)