Your argument reduces to: "I only login once per device and never logout, so autojoin is effectively useless to me, therefore it's useless to everyone." In your world, you are always online and wish for your clients to be (or appear to be) always connected.
It works just as you like it - good for you. But not everyone lives in your world - maybe even 99% of people do, but that's not everyone. I'm clearly in a minority, and apparently insane for not working the way you do, but some people aren't always connected,
nor do they want to be.
> 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)
There is the subtle difference of whether to join/leave silently on reconnect, and potentially ask whether to join on updates, but these flags aren't necessary for that.
> - 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)
Maybe the user wants to be asked first, i.e. don't blindly join on this device even if another device is already joined. Arguably, it wouldn't be a big deal to ask every time in this case, especially since 'nobody' ever purposely logs out, so it will only ever
happen once per device (in your world.)
> 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)?
User initiated login, which may be explicitly entering username and password, or a 'login/online' button/menu (using stored credentials.) This only happens once per device in your world, and 'nobody' ever logs out; I am nobody - I logout, I close apps, I don't
want to be persistently connected. App restarts (user or system initiated) are usually considered reconnects (since the user didn't explicitly logout), but the line can be blurred depending on circumstances.
> 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.
You've mentioned what other messaging protocols do; as I understand it, most don't even have an explicit concept of separate devices, your account is either joined or not and that applies across all devices. If there is only one flag (autojoin=joined) then
you still have the same choice to make - join if another device did, or don't (preferably, ask the user explicitly, or implicitly via a "sync my groupchats/rooms across clients" setting.) Section 4 of the XEP currently suggests clients SHOULD join/leave when
another device does (upon autojoin value updates.)
> 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'm nobody, I do this. Not to be funny, I actually do; much like saving URL bookmarks that I don't have time to view right now. Autojoin defaults to false because this was part of the original usage.
> "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.
Again, this is me - but I explicitly leave, so there's no need to guess a reasonable timeout, though it may still be useful to some.
Ultimately, my argument is that I want to set autojoin to false and for it to remain false, and not to be changed when I happen to join a room; obviously when it's now used in place of 'joined', that's unavoidable. But then, I never want to autojoin a room,
so arguably that should be a client setting and the attribute is useless to me too.