So, to summarize these tables: - on-reconnect and on-update are exactly the same, completely ignore `autojoin` and only look at `joined`. If it's set, join, if not, leave (where obviously it's not possible to leave when not joined or join when already joined) - on-login completely ignore `joined` and only look at `autojoin`. If it's set, join, if not, do nothing (because on-login you surely are not joined) So the only point when you see a difference between `joined` and `autojoin` is on login. How and where do you do the distinction between on-login and on-reconnect? Is a login when I enter my username and password (99% of users only do this once per device)? Is it when the username/password is sent to the server (which typically happens at reconnect)? Is it when I restart the app? What if the client is regularly killed by the OS in the background and then restarted (common on mobile platforms)? There's two situations where you already wrote that they're somewhat weird and both are when `autojoin` and `joined` do not match. When `autojoin` is set and `joined` is not, and you have one online device (that is not joined the room), and then a new device goes online and does the on-login flow, it will join the room (because `autojoin` is set) and then set the `joined` flag (because it joined) causing the other online device to join (through the on-update criteria). I doubt that anyone expects that going online with one device means to join a room with their other device. In the end, your proposed `autojoin` flag is just `joined`, but after next login. I can't imagine anyone ever had a usecase "I found this MUC, and I'd like to join, but only some random point later, not now". "I want to join the room now, but not stay in it forever", is indeed not unlikely, as is "I want to leave for the day, but want to be back soon", however finding the time for these leave/rejoins is not trivial and linking it to some "login" also is really arbitrary and probably completely broken for everyone that has an always-online device. So maybe we should consider adding `join-after` and `leave-after` to the bookmark (e.g. "Leave after I hadn't written a message for 24 hours") or something similar to handle these usecases in a generic fashion not tied to some arbitrary "login" point in time. Marvin On Wed, 2024-08-28 at 17:06 +0000, Tedd Sterr wrote:
A: 'autojoin' = whether to join automatically at login J: 'joined' = current/previous known joined state
``` A J | on login ----+------------------------------- 0 0 | don't join 0 1 | don't rejoin (possibly ask - likely just forgot to leave) 1 0 | join 1 1 | rejoin
A J | on reconnect ----+------------------------------- 0 0 | don't join 0 1 | rejoin 1 0 | don't join (already left explicitly) 1 1 | rejoin
A J | on update (not already joined) ----+------------------------------- 0 0 | do nothing 0 1 | join (possibly ask) 1 0 | do nothing 1 1 | join (possibly ask)
A J | on update (already joined) ----+------------------------------- 0 0 | leave (possibly ask) 0 1 | do nothing 1 0 | leave (possibly ask) 1 1 | do nothing ```
I get that this isn't necessary for the 'modern' always-online way many of you use rooms, but you can just set autojoin to true and forget about it; does that mean everyone else must be forced to use it in the same way that you do?
In terms of asking first, clients can have a "sync my groupchats/rooms across clients" setting - if true, asking isn't needed.
In any case, changes to autojoin don't alter current joined state.
_______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org