28 Aug
2024
28 Aug
'24
12:23 p.m.
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(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org