jdev - 2021-06-29

Are there any cases where a MUC will send an error when you try to leave it? I don't see any, and I can't imagine why, but do any servers do this for some reason?

the Hotel California error...

Right now I'm treating all self-presences of type "error" as failed join requests, but I can't tell if that's right.

hah, that took me a second

> moparisthebest > the Hotel California error… You win Tuesday.

what is it with hotel california?

meh, I don't get the Hotel California reference

Sam, typical error case on a MUC leave presence would be if you aren't in the MUC in the first place

flow: last verse: https://www.youtube.com/watch?v=BciS5krYL80

You can check out any time you like, but you can never leave.

Good point RE leaving error.

You can of course get an error for any stanza to a remote server that fails to be delivered

Also a good point.

There is no good way to assiciate an error with the request that created it then; that's unfortunate

Hmm?

I guess I could keep track of all join/leave requests the user makes then handle self-presences in that order back from the server. This is going to be a pain.

Oh, I see, in the case that you join the same room multiple times

Oh yah, sorry, trying to figure out what to do if the user calls Join three times and Part twice or something in different orders.

is that even possbile? from the same full jid that is?

It's not possible at a protocol level, but sure it can happen

Multiple joins are a thing; the first will join the others will either change the nick or just re-sync.

I just need to keep track of whether they've joined or not and if it gets out of sync it gets out of sync. It's just how MUC works.

so the protocol design flaw in muc is that there is no way to distinguish between a join and a nick change?

That's definitely one of them

I think the main problem is that it's easy for the server and client to get out of sync. Obviously this could always happen in anything due to bugs and what not, but with MUCs it seems common and expected.

That's not really the flaw. To solve this really you'd need a three-way handshake for joining.

What Kev said.

> There is no good way to assiciate an error with the request that created it then; that's unfortunate. The id? And you should know who causes the error because of the by stamp. ✏

Heh

I don't think there necessarily is an error that will be mirrored, sadly.

An ID, I mean.

It's a "might" in XEP-0045 for the self presence to have the same id

I didn't think it mentioned it at all, but either way.

(the text below example 23)

Ah yes, thanks

As always, I'd like to point out that all optional features are basically worthless w/o a way to check if they'll happen or negotiate for them or something.

MattJ, not sure why you'd nee a three way handshake. woudln't it be sufficient to make the intent clear in the request: "I want to join this MUC" or "I believe I am already joined in this MUC and want to change my nick to X"

I don't think nick changes are the issue

Okay, I think the issue is actually with my code and I can do this easily enough. To rephrase:

Nevermind, still can't figure out how to phrase this well.

Anyways, thanks for the help; shouldn't be an issue, I just need to keep track of order and direct self-presence errors to whatever handler was next in the order (between join/part/rename handlers)

That sounds like it's just waiting to go wrong

Use the id

> It's a "might" in XEP-0045 for the self presence to have the same id I thought the problem was knowing whether it was self presence or a routing error? A routing bounce will have the same id (and should have the bouncer stamped).

If you send a join request and the join fails, you will get an error reply with the same id

Maybe I’m missing the point.

I understood the problem to be about when the success/error result gets lost

Which ordering doesn't solve

Ah.

I may well have misunderstood :)

The id may not be the same though?

What makes you think that?

If a server sends an error in response to a stanza, it will always reflect the id

Whether that's a failure to join the room, or a delivery error on the way to the MUC, or anything

Didn't the spec literally say 'might'?

6120? No, I don’t believe so.

No, the text I pointed out in '45 is about the success case, not the error case

That aside, it's a prime candidate for something that should be tested in current implementations and tightened up

We've done that for other things in MUC in recent years, and this is a good candidate

It doesn't change the fact that you should use the id for errors, and hope that the server also does the same for the success case (optionally have some fallback logic if it doesn't, depending on how common this behaviour is and how robust you want to be against servers that don't do it)

On the other hand a success is a success, it means you are joined, no matter how many outstanding join requests you have

Ahhh, right, 6120 guarantees that *errors* mirror the ID, not MUC guarantees that all responses mirror the ID. Gotcha, yah, that makes sense

(sorry, just got back and was catching up on the backlog)

Prosody mirrors the ID on successful presences, ejabberd doesn't.