UPDATED: XEP-0402 (PEP Native Bookmarks)
Version 1.2.0 of XEP-0402 (PEP Native Bookmarks) has been released. Abstract: This specification defines a syntax and storage profile for keeping a list of chatroom bookmarks on the server. Changelog: Encourage clients to immediately leave the room if they receive a bookmark notification with autojoin set to false (mye) URL: https://xmpp.org/extensions/xep-0402.html Note: The information in the XEP list at https://xmpp.org/extensions/ is updated by a separate automated process and may be stale at the time this email is sent. The XEP documents linked herein are up-to- date.
Changelog: Encourage clients to immediately leave the room if they receive a bookmark notification with autojoin set to false (mye)
I disagree strongly with this change. "The XEP describes an automated way to sync which MUCs you are joined." It could additionally do that, but it doesn't, and that was not the original purpose of bookmarks. The stated purpose is "a syntax and storage profile for keeping a list of chatroom bookmarks on the server." XEP-0048 also allows for bookmarking URLs, but obviously that's better left to web browsers; this does, however, point towards the actual intention of "I want to save these useful links to MUCs/websites for potential future use" - which is not "I want all of these links to be opened automatically when I log in." The autojoin attribute adds additional utility, but it's not the purpose of the XEP; and autojoin is not even for syncing which MUCs you're joined. Table 1 clearly defines the purpose of the 'autojoin' attribute as "Whether the client should automatically join the conference room on login", i.e. whether the client should join the given MUC immediately after login, without the user having to do so explicitly. Unfortunately, some clients have (wrongly) decided to repurpose the attribute to keep track of which MUCs the client is currently joined - while this may be related, it is not the same thing. If such behaviour is desirable (of course it is) then it should be an additional 'joined' attribute. "But the only time I (as a representative of all sane persons) ever leave a MUC is because I don't want to return." That works for you, but in that case this change doesn't really affect you - the only time you might set autojoin to false is to leave permanently, and so you're more likely just to delete the bookmark entirely. For those of us (arguably, not so sane persons) who do not want to be permanently joined, and prefer to join and leave by choice, autojoin should have a constant value of 0; instead, this behaviour means that if I forget to leave each individual MUC before logging out, I will be forced to join them the next time I login, even though I had explicitly set autojoin to 0 because I specifically did not want that behaviour, i.e. the client is not doing what I asked. "But section 4 says clients should join the MUC when autojoin is set to true, so this is just matching the opposite behaviour." Yes, but actually no. If I set autojoin to true then it's a sensible presumption (but still a presumption, not an explicit request) that I would also like to join the MUC now rather than waiting until the next time I login. If I set autojoin to false, that is only an indication that I want to choose when I join - it does not mean I suddenly want to leave. You can argue that join if added and leave if deleted are weird, but there is some sense behind them; there is little sense in making "don't autojoin" equal to "leave now." "Many clients are already doing these things, so it's just making the XEP match actual behaviour." Some clients did the wrong thing, others copied that behaviour assuming it must be the right thing, so now they all do the wrong thing; so, let's now mandate the wrong thing so at least everyone can be consistently wrong. No. "They're all SHOULDs, so clients could allow not doing this." They could (they won't), but why are we making the wrong thing the default? If anything it should be the other way. TL;DR: autojoin only means whether to join automatically on login, it's not for tracking/controlling which MUCs you're currently in; "I don't want to join automatically" is not equivalent to "I want to leave now."
TL;DR: autojoin only means whether to join automatically on login, it's not for tracking/controlling which MUCs you're currently in; "I don't want to join automatically" is not equivalent to "I want to leave now."
I completely agree that the decision of what to do wrt join/leave should be up to the client and not part of the XEP at all. However the XEP already had language like "On the other hand, if the event is a retract notification, the client SHOULD leave the room immediately." and so this led to specifying an inconsistent UX (as opposed to not specifying UX at all, which would be preferred). I think the solution in practise will be to ignore the SHOULD in clients that know what they are doing.
On Mon, 26 Aug 2024 at 17:06, Stephen Paul Weber <singpolyma@singpolyma.net> wrote:
TL;DR: autojoin only means whether to join automatically on login, it's not for tracking/controlling which MUCs you're currently in; "I don't want to join automatically" is not equivalent to "I want to leave now."
I completely agree that the decision of what to do wrt join/leave should be up to the client and not part of the XEP at all. However the XEP already had language like "On the other hand, if the event is a retract notification, the client SHOULD leave the room immediately." and so this led to specifying an inconsistent UX (as opposed to not specifying UX at all, which would be preferred).
I think the solution in practise will be to ignore the SHOULD in clients that know what they are doing.
That sounds awfully like a MAY. SHOULD is "MUST unless you know what you're doing, and you probably don't". I'm also unconvinced that specifying whether clients leave chatrooms or not when things happen is "UX" - it's client behaviour, and that seems entirely within the remit of a XEP. It might *also* have an effect on user experience, too, but that's OK, as many things we do have an effect on UX. We assume, for example, that if you send a message to a client it'll be visible to the user sitting in front of it - that, too is UX. We don't specify how that might occur. Dave.
That sounds awfully like a MAY. SHOULD is "MUST unless you know what you're doing, and you probably don't".
Sure. I'd rather it be non-normative, or even omitted, but that's not a change we can make at this stage I think.
I'm also unconvinced that specifying whether clients leave chatrooms or not when things happen is "UX" - it's client behaviour, and that seems entirely within the remit of a XEP.
I disagree. Client behaviour, especially user-visible behaviour, is exactly UX and is up to the developers of the app based on their use case, etc.
experience, too, but that's OK, as many things we do have an effect on UX. We assume, for example, that if you send a message to a client it'll be visible to the user sitting in front of it
We perhaps commonly assume this, but we don't require it in the spec and indeed there are clients which ignore various messages based on various criteria and I think that is a valid thing for them to do.
On 26 Aug 2024, at 21:27, Stephen Paul Weber <singpolyma@singpolyma.net> wrote:
That sounds awfully like a MAY. SHOULD is "MUST unless you know what you're doing, and you probably don't".
Sure. I'd rather it be non-normative, or even omitted, but that's not a change we can make at this stage I think.
I'm also unconvinced that specifying whether clients leave chatrooms or not when things happen is "UX" - it's client behaviour, and that seems entirely within the remit of a XEP.
I disagree. Client behaviour, especially user-visible behaviour, is exactly UX and is up to the developers of the app based on their use case, etc.
experience, too, but that's OK, as many things we do have an effect on UX. We assume, for example, that if you send a message to a client it'll be visible to the user sitting in front of it
We perhaps commonly assume this, but we don't require it in the spec and indeed there are clients which ignore various messages based on various criteria and I think that is a valid thing for them to do.
Making my best effort to derail the thread - actually 6121 *does* have some normative rules about presenting messages to the user :) /K
On Mon, 26 Aug 2024 at 21:27, Stephen Paul Weber <singpolyma@singpolyma.net> wrote:
That sounds awfully like a MAY. SHOULD is "MUST unless you know what you're doing, and you probably don't".
Sure. I'd rather it be non-normative, or even omitted, but that's not a change we can make at this stage I think.
I'm also unconvinced that specifying whether clients leave chatrooms or not when things happen is "UX" - it's client behaviour, and that seems entirely within the remit of a XEP.
I disagree. Client behaviour, especially user-visible behaviour, is exactly UX and is up to the developers of the app based on their use case, etc.
I think there's many shades of grey between the extremes of "this should be presented to the user in a purple dialog box" and "the client SHALL leave the chatroom". There's lots of things that affect the user experience in all manner of ways. We shouldn't prescribe how these are presented, certainly, but the fact they happen is important. Or at least might be - the key to my mind is if you have two clients, one of which expects that setting autojoin to false (in this case) will cause all clients to leave, and the other does not, is this going to create a horrible UX due to the interoperability gap? I would personally expect that removing a bookmark entirely would (reasonably) cause clients to leave the chatroom - but merely removing autojoin would simply cause the clients not to join automatically in future. Some clients might choose to leave, others might not, depending on whether they consider the room to have been "only autojoined". Otherwise, setting autojoin to false is the same as a retraction, which seems to me like the autojoin flag is entirely redundant, and should simply be removed. (It reminds me of an IMAP client issue from about 25 years ago, where some clients would immediately EXPUNGE messages with the \Deleted flag set, whereas others treated the \Deleted flag as temporary "trash can", from which messages could later be recovered if needed, and EXPUNGE as the "empty trash can" UX. The latter was actually the intent of the spec, and if you used multiple clients, the immediate-EXPUNGE type would constantly "empty the trash can" of the other.)
experience, too, but that's OK, as many things we do have an effect on UX. We assume, for example, that if you send a message to a client it'll be visible to the user sitting in front of it
We perhaps commonly assume this, but we don't require it in the spec and indeed there are clients which ignore various messages based on various criteria and I think that is a valid thing for them to do.
As Kev notes, we actually do require it in various places. But whether a client leaves a chatroom and when is absolutely a protocol behaviour, and we should stipulate it firmly (ie, with normative language) if there's an interoperability concern - as, indeed, XEP-0402 has done since JC and I wrote it. Dave.
On 27 Aug 2024, at 09:26, Dave Cridland <dave@cridland.net> wrote:
Otherwise, setting autojoin to false is the same as a retraction, which seems to me like the autojoin flag is entirely redundant, and should simply be removed.
I’m not sure that’s true, as in that scenario a bookmark without an autojoin can still act as a bookmark for easy rejoin (ISTR I did this in Swift at one point). /K
Hi, I think all of these discussions are merely caused by wording of the attribute. For historical reasons, it's called `autojoin`, but what we nowadays want to say with it (or how most clients want it to be used) is `joined`. Maybe we want to add a note to the XEP that explains this? The concept of joining a MUC in XMPP does not reflect how people use messaging these days. I think this is widely understood and is for example also included in the design of MIX. Barely any other messaging protocol requires clients to join every room the user wants to be part of every time they connect. IRC is one notable exception and we all also know that most IRC users use bouncers to bypass this and other protocol restrictions. When it comes to UX, I would assume most people nowadays assume that leaving a room using their account on one device also means they would leave on other devices with the same account. Similarly, people also assume that if they are joined in a room now, they would still be joined if their client needed to reconnect (due to a network outage or them switching from one cell tower to another). And finally, I think it's perfectly fine to say in a XEP "when a client receives message X, it SHOULD leave the room", even if that affects UX. In fact, there are other messages already that have a very similar effect on the UX, e.g. the user being kicked from a room. How the client displays that they were kicked or left on another device is entirely up to the client, but what remains is that it should no longer be considered a member of the room. If a client developer wants to, they can ignore both (not leave when autojoin is set to false or immediately rejoin after being kicked), but it's certainly a bad idea. In fact it's so much and obviously a bad idea, that nobody even bothered to add a note to 0045 that clients SHOULD NOT automatically attempt to rejoin after being kicked. Marvin
I completely agree that the decision of what to do wrt join/leave should be up to the client and not part of the XEP at all. However the XEP already had language like "On the other hand, if the event is a retract notification, the client SHOULD leave the room immediately." and so this led to specifying an inconsistent UX (as opposed to not specifying UX at all, which would be preferred).
I think the solution in practise will be to ignore the SHOULD in clients that know what they are doing.
XEPs are meant to prescribe behaviour - what happens, and even how it happens, but not how it is presented. Showing a dialog is purely presentation - it has no consequences outside of itself, and the interaction need not even be through a dialog. Leaving a MUC is an action - something actually happens; how that is presented to the user is out of scope, but it's a thing that happens and has consequences. The use of SHOULD tends to confuse people due to its common (non-normative) usage. MUST means "do this or bad things will happen"; while SHOULD means "do this or bad things will happen (but if you really insist…)" So, no, clients SHOULD NOT be ignoring 'SHOULD' - the 'SHOULDs' SHOULD NOT be there in the first place when they are prescribing incorrect behaviour. The root issue is that the purpose of the 'autojoin' attribute is being misinterpreted and so it is misused; I suspect the advice about joining/leaving when a bookmark is added/removed may have influenced this. I don't have an issue with those things as suggestions - it does make sense to join now when adding a bookmark with autojoin, and it does equally make sense to leave now when removing the bookmark; ideally, though, you would offer to do these things and allow the user to decide at the time. What does not make sense is forcefully leaving when autojoin is changed from true to false. Again, this results from 'autojoin' being misused in place of a 'joined' attribute. Would anything break if a 'joined' attribute were added? Then we could gradually migrate to using that, and autojoin regains its actual purpose.
Hi, On Tue, 2024-08-27 at 14:18 +0000, Tedd Sterr wrote:
Would anything break if a 'joined' attribute were added? Then we could gradually migrate to using that, and autojoin regains its actual purpose.
Well, let's play the scenario where we had `autojoin` and `joined` independent. What is the expected behavior of clients? A=`autojoin`, J=`joined` Client connects: None -> Do not join room A -> Join room (`autojoin` is true) and change to A+J (because we joined now) J, A+J -> Join room (`joined` is true) Client is joined and receives update: None -> Leave (`joined` is false) A -> Leave (`joined` is false) and then join on next connect (`autojoin` is true) J, A+J -> Stay in Room Client is not joined and receives update: None -> Do not join room A -> ? Either join (and change to A+J) or ignore and join on next connect (`autojoin` is true) J, A+J -> Join As you can see, the interpretation of the `joined` attribute is that it behaves exactly as the `autojoin` attribute is defined in the updated XPE-0402. The only difference would be that `autojoin` could be interpret as only go in effect after reconnecting. `autojoin`, when true, would eventually be copied into `joined` and does not matter once `joined` is set. This seems pretty useless IMO. Why don't we just keep `autojoin` if it has effectively the same meaning as soon as the first client reconnects (which may be a few minutes later, if you have an unstable connection)? Marvin
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.
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
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.
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.
I think you are a bit late to the party there. Since years in Gajim, we don't expose the user to protocol details of bookmarks. We removed all mentions of bookmarks. No user does need to know the protocol details how a client syncs known chats. Why would a user need to learn what "autojoining a MUC" means when using Gajim. I think your fear that this language change in the XEP makes your usage impossible is overblown. What the XEP describes for me is a fair, common sense implementation, in absence of any advanced settings that your client may offer. I think all your wishes can be implemented by a client who offers more control for that, call it "advanced multi device muc join settings". Is this discussion maybe just a different opinion on what "SHOULD" entails? When i read the RFC keyword definition, it seems ok for me that a developer offers settings that ignore this SHOULD. I think there are valid use cases for ignoring the autojoin flag, or storing join information locally instead of syncing it to pubsub etc. and this SHOULD would not stop me implementing settings to satisfy such use cases. Regards Philipp
participants (7)
-
Daniel Gultsch -
Dave Cridland -
Kevin Smith -
Marvin W -
Philipp Hörist -
Stephen Paul Weber -
Tedd Sterr