jdev - 2022-12-01

so the muc xep has no "service restart use case". As I understand it, 332 means: "I'm shutting down, bye bye, see you some day in another life maybe lol". Isn't there a "I'm shutting down, but I'll probably restart soon, so maybe you should try re-joining automatically every few minutes?" ✏

Zash, the lua snippet you pasted only included code 332, but shouldn't prosody send status code 110 too since this is a "self-presence"? maybe it's added somewhere else when presence-to==user-session or something?

nicoco, I believe Prosody no longer sends 332 (partly for this reason)

Local users have to reconnect (their whole XMPP session) anyway on restart, and remote users don't get disconnected (in the happy path)

MattJ: I see. So clients really need to implement "muc self-ping schrödinger's cat" now to avoid being in the "I think I'm connected but I'm really not" state

They do, and they always did

Prosody's new behaviour means that it works properly more often than it used to

I haven't dug enough to understand if this is sarcasm or not? all clients implement muc self-ping!?

No, you said they "need to implement it now", and I'm saying they always needed it

oh OK, right.

and just so I'm sure I understand. prosody's mucs have some persistent storage for the "connected resources" so that it's persistent across restarts then?

Yes

So in the happy case, nobody notices a remote Prosody MUC service restarting

If you send something during the restart, your server will give you an error bounce for that stanza if the MUC is unreachable, and your client will (should) reconnect

If the server doesn't come back (e.g. it crashed) or s2s fails silently and you never send anything, that's where mod_ping_muc helps

Both those cases are unrelated to Prosody's restart behaviour, since they can happen anyway

I see. And there's no way for the MUC service to query a bare JID, sth like "hey! what resources of yours believe you are still joined? nothing happened, just asking for a friend"

No, the MUC service doesn't have a subscription to the user, and isn't permitted to know about any resources that haven't explicitly joined the MUC

OK, thanks for your replies! I don't think that for a MUC gateway, it is a good idea to behave like prosody. When prosody is down, no messages can go through, so it's OK to respawn "unnoticed by clients". If a gateway MUC component wanted to behave like prosody, it would have to keep (persistent) track of both joined resources and chat history, then on restart fetch the "missed" messages and send them to the resources with a delay tag. This is because, when the gateway is down, the legacy service can still have messages being exchanged. So I'd rather send send "kick" (status code 332) and let clients reconnect; then it's up to the clients to correctly retrieve chat history for this MUC. Since most other IM services have a "fetch group history" endpoint, this seems a lot less trouble to implement... I am thinking out loud here, anyone feel free to chime in and tell me if I overlooked something.

But ideally, a status code 33x meaning "I'm shutting down, but I'll be up again in not too long" would be better than this 332… ✏

Isn't it possible for s2s (only?) to send reset? at the stream level

pep., reset, the stream error? for what purpose?

Telling clients to reconnect?

Not aware of anything like that.

But that's kinda the goal of mod_ping_muc, it activates when a s2s link is closed and sends a xep-0410 ping on behalf of local clients to find out whether they are still in remote MUCs

Zash: The MUC sends the ping? Local clients? Remote MUCs?

pep., your local server sends ping (implicitly attempting new s2s)

it's basically the same as XEP-0410 but happening on the server instead of clients

Ah this way around, ok

and happening at the time of s2s disconnection (regardless of reason) since the server sees this but clients don't

So the module is loaded on the account vhost not a MUC

Ok

In the case where the MUC host shut down, it can't very well be sending anything while it's down.

Also race conditions between flushing buffers and `exit()` can result in unclean shutdowns, so anything sent from the MUC might not make it.

Or the MUC might have crashed, can't very well tell anyone about that.

Sam, you asked earlier how to create a room with Gajim

Gajim -> Create Groupchat

Its in the Menu

Its rather sad that nobody could give you this info in a room with 300 people that use Gajim

Bystander effect? "Someone else will answer"

yeah someone answered, sadly a person with no clue

Take it as a UX or documentation bug report? :)

lovetox: the room is on a server that's not the same as the domain, as far as I can see that just requests a name, not the domain to create it on

in the dialog are 2 options

(I did try that, I foolishly typed in room@whatever and it created a room with that name on the server of my JID :) )

private and public

its true that you cannot choose a remote address for private chats

What does that have to do with the domain?

but if you click public it shows you a jid field

where you can put it anything you like

Oh, weird, I see now; I don't get what that has to do with it being public or private though, but I wanted a private room at my other group chat server anyways

yes just create a public room there

go into the config, and make it private

I don't want a public room though ¯\_(ツ)_/¯

Oo wow

Is this some technical restriction I don't know about? I don't see what the address option has to do with the public/private option

But yah, I definitely never would have found this hidden behind the public option

For a guy writing xmpp software i suprised how hard this is :D

I dunno, I guess consider this a UX report like Zash said, I have no idea how this would be obvious to anyone

How common is it to create private chats at remote MUC hosts?

Thats the UX, it should not be obvious

How common is it to have >1 available?

Is gajim only for people who also develop XMPP software?

you are the first person ever who asked that question in 5 years

and we still provide a option for you

I still don't understand what these options have to do with one another or why I'd look for that box under public

I mean, I assume other people have group chat domains that are for a specific project or organization or something, no? I'm not saying this is super common or that it should be a thing that's specially supported, just that I never would have found that dialog where it was and I don't understand the logic of these two options being tied together.

nobody says they are

I didn't understand that; nobody says what are what?

that public has anything to do with creating jids on a remote server

Then why are they tied together in the UI? That's what I'm trying to understand

because we dont want to show users a JID field, because they dont know what to do with that

Why would they know what to do with that if they pick "public"?

Sam: I think the UI comes from https://docs.modernxmpp.org/client/groupchat/

users who create public rooms are most of the time advanced users

they know what to do with that

Okay, thanks, that was the reasoning I was trying to get to. I *really* don't think that's true though.

Anyways, fair enough, you say the UX makes sense, I say it doesn't make any sense and I never would have found that if you hadn't told me. I dunno, ignore it if you want or ask others or do whatever you do to figure out UI I guess and consider this a report. Thanks for letting me know.

i never said its obvious, and thats not by accident, most server block foreign users creating rooms, this is really a edge case

but if i think about that dialog, instead of public and private, we could simply do a advanced box

and offer a public switch there or something

Advanced makes a lot more sense to me. I'm not sure why "public" would be advanced, but if you're going to have an address at another server I could see that being advanced.

If it were me I'd just have name, server (pre-filled to their domains MUC server), public/private. No need to hide stuff if there are only like 4 things.

(oh, and description or whatever else was already on the form)

hm i dont agree, as i said you overestimate how much people care about the JID

they want to create a groupchat, and give it a name

I don't think people care about the JID, I just don't think the fact that no one cares means it needs to be hidden.

At least not in the way it is now which makes no sense. If it were behind an advanced flag that would make sense, I just don't think it's necessary for a single field.

hm so how would a user not accustomed with the protocol details, know that he does not fill out that field?

Because it's pre-filled to their server already.

thats not enough

Keep it simple, hide distractions. People fiddle with every knob once those are visible

you need a local part also or

They don't need to know protocol details anyways, they know they have an address like user@whatever.com already, that much they have to know to use XMPP at all.

Sure, it says "name" at the top or whatever.

Same as it does now, that part doesn't have to change.

but they ask themself, what it is, do they have to change it etc

and the answer is always NO

you dont need to care about this at all

I think you're underestimating your users, they literally already have to know that it's at a server already.

only in the edge case that you need to create a room on another server

which probably going to fail, because almost no server allows that

We once had a user click a "copy from production" button *in production* which broke stuff because they "wanted to see what it would do"

because of spam

moparisthebest: yes.

lets leave it at that, i agree there should be advanced option

i dont agree showing a user a groupchat adress

<button>⚠️ DO NOT CLICK</button>

Yah, I having an advanced button seems like it at least makes sense

Create: [ private chat | public channel | custom (expert mode) ]

I promise you 100% of users will pick expert mode because they're experts!

Create: [ private chat | public channel | Click here Sam ]

RE users filling out anything even if you tell them not to: we have a field in the registration form for social.coop that says something like "Leave this field empty, it is a spam trap" or something and people constantly fill it in with random stuff and ask why their application ended up in spam. TBF, that field should really be hidden by CSS, but still.

Zash: haha yea it was a bug that the button showed up on production, but clicking it literally had a pop-up that said roughly "this will wipe all data and copy from production are you sure?" And they still clicked yes